#自分もトピックブランチ毎に clone しています。branch の スイッチで build dependencies がおかしくなったりフルビルドになったりと困るので。
#やっぱそれがいいのかなあ。ローカルでもいくつも実験的なブランチを切ってるとだんだんどれが何をしてたのかわからなくなるしなあ。
#ああ。ありますね。＞分からなくなる。できる限り一日の最後にローカルマスターにマージしてしまうようにしていますが、そううまくもいかないんですよね。
#.自分の記憶力との闘いですよね。なのでぼくの作業リポジトリはやたらと短命なブランチがいっぱい転がってて、本流に取り込まれることなく打ち捨てられた屍が累々と...
#プロジェクト名.トピックブランチ名 という名前で clone しています。 mosh.jit / mosh.master / mosh.mona とか。
#あとよくやるミスが、debug print 追加のコミット id を覚えておいて、バグがとれたら revert するとメモしているのに忘れてしまうとか。
#あとたくさんのブランチを頻繁に切り替えると、気がついたらstashがどんどん積み重なっているという罠
#stash は 1段まで。としています。絶対忘れるので。緊急避難時しか使わない。
#それはとっても正しい。自分も1段しか使ってないはずなんだけど。おかしいなあ、気がつくと4つくらいたまってるんだ。
#stash は本当に「どこかに消えてしまう」可能性が高いですよね。日をまたいだら確実に。
#何かの都合でpopじゃなく
#applyして、そのままpopを忘れてた、って可能性が高いか。
#日をまたぐと何だったか忘れちゃうからねえ>stash
#あーあと、cloneした場合、Emacsで別ブランチの同じソースを開いてて間違えちゃうことない? それが怖くてcloneに消極的。ブランチで切り替えた場合はEmacsga
#Emacsが警告してくれる。
#あまり間違えないですね。
#;; 同一ファイル名を開いた時に, [ファイル名]<[ディレクトリ名]> と
;; 表示する.
(require 'uniquify)
(setq uniquify-buffer-name-style 'post-forward-angle-brackets)
#これのおかげかも。
#一つ大事な事を忘れていました。
#おおそれは知らなかった。ディレクトリ名は差があるところだけ抽出してくれるんですね。
#そうです。
#スイッチの時に ln -s ~/mosh.jit/ ~/mosh みたいなもことをしています。こちらの方が大事だ。
#VC使ってるとGitのブランチ名も表示してくれるんだけど、ブランチ名が長くなりがちだからいまいちだった
#自分はブランチ名を zsh のプロンプトに表示しています。Emacs では気にしたことなかったです。
#zshのプロンプト!? おもしろいですね. どんなかんじで表示していますか?
#設定自体は .zshrc に
#autoload -Uz vcs_info
zstyle ':vcs_info:*' formats '(%s)-[%b]'
zstyle ':vcs_info:*' actionformats '(%s)-[%b|%a]'
precmd () {
psvar=()
LANG=en_US.UTF-8 vcs_info
[[ -n "$vcs_info_msg_0_" ]] && psvar[1]="$vcs_info_msg_0_"
}
RPROMPT="%1(v|%F{green}%1v%f|)%~"#こんな感じ。どこからかコピペしたものです。
#しかし続々とバッドノウハウが出てくるあたりが git の何かを表しているな。問題を解決しているが、新たな問題を生んでいるという。
#ブランチ名見て何やってたか思い出せるようにしとくと、かなり長くなるんですよ。[チケット番号]-[数単語で説明]みたいにしてるんで。会議の時にはチケット番号でやりとりするんで入ってないと不便だし、かといって番号だけから即座に内容思い出せないし。
#ブランチの粒度がとても小さいのですね。それだと色々大変そうだ。
#さらにベンチマーク用に細かく条件を分けたりするとその識別子が後ろにくっついて。emacsのモードラインでははみだしてしまって結局判別できないという。
#とりあえずuniquifyのそのスタイルは便利そうなので早速使います。
#おもしろいですねぇ．ブランチングをそれほど細かくやったことがない．
#モードラインではなく, windowのタイトルに表示するとか...?
#んー、Emacs windowは通常4分割 (縦横2つづつ) くらいで使ってるからなあ。カーソルがどこにあるか見なくてもどのバッファがどれかわかってほしい
#window分けじゃなくてframe分けにするのは面倒？
#Emacsがwindowマネージャなのか．
#なるほど．
#画面全体を1個のEmacsが覆っている派です
#ウィンドウを透過モードにして下に敷いたエディタの画面を参照しながら上のエディタで編集する、というスタイルの人を見たことがあるけど真似できなかった。
#Emacsをタイル型のWMで使うよりも使いやすいのかな？ > 画面全体を1個のEmacsが覆っている派です．
#正直なところ比較した結果辿り着いたのではなく昔からコレでやってきているだけ、というところです。EmacsもGUIのやつじゃなくてターミナルを全画面に引き伸ばした中で動いてるだけで、そのターミナルの中でscreenを使ってmulti-ttyなEmacsが動いているという...
#学生のときの師匠が「cdするくらいならもう一個端末開く」人だったので画面がウィンドウだらけだったのですが、screenを覚えてからはどんだけ端末開いても画面が散らからないのでそのまま現在に至ってます :-)
#なるほどなるほど．
#他の人の作業風景って見てるといろいろ勉強になりますよね
#ところで，gitなどで細かくブランチングするとcommitの際のconflictが少くてすむようになるものですか？
#てすてす
#もしもし
#なおった。一時的にchatonがおかしくなってたかな。
#いや、サーバマシンはokだけどsshセッションも蹴られたので、ネットワークがおかしかったのかも。
#蹴られたっていうか既に張ってあったのが切断された
##twitterから快気祝いコピペ：コンフリクトを解消するために考慮しなければならない範囲（粒度）が小さくなるのでハンドリングがしやすい、という理解です。ぼくの場合は。
#コンフリクトについては細かくブランチというよりこまめにコミット(パッチ作成)の方がいいかな。自分の場合、細かいブランチになるのは、多人数で作業してて、一応ひとつのタスクについては完結してからじゃないとマージできないから、ってとこ。
#branchした作業をmergeする際にconflictが起こりやすいような気がしますが，そういうことはあまりないですか？
#多人数でやってる以上、branchしようがしまいが同じところを触ってればconflictするし、触ってなければconflictしないでしょう。branchの有無とは関係ないような。
#ああそうか多人数でやっているときは，同じところを触るかどうかだけですね．1人でやっても違うタスクを並行してやれば，それぞれは他人だから，やっぱり多人数でやっているのと同じですね．なんかねぼけたこといっていまつた．
#>Emacs windowは通常4分割 (縦横2つづつ) くらいで使ってるからなあ
#へえ。今度機会があれば、実際に見てみたいです。自分は分割なしで切り替え派です。
#emacs は横 80 桁の kterm で使う派。縦は 24 と画面上下一杯を切り替える。 RT maru: 正直なところ比較した結果辿り着いたのではなく昔からコレでやってきているだけ、というところです。EmacsもGUIのやつじゃなくてターミナル
#昔は80桁でC-x3分割はしない、って方針だったんだけど、最近はスクリーンの横幅が広がったんで、80桁ふたつぶん入れられるんですよね。(知り合いは昔からフォントの方を小さくして80桁2つ収めてたけど)
#バッファはがんがん分割する派。同一ソースの別々の位置を開けることも多い。それができないエディタは苦痛。
#縦横無尽に分割しますよ :-)
#80桁ルールは昔は意識してた（O社のRDBMSのコードがそうだった）けど、Javaが出てきたあたりから横方向に伸びるのを抑制するのは無理だと悟りました。
#同僚はコードの全体像を俯瞰したときは6ドットフォントとかでコードの「形」を頭に入れるために眺めてますね。中身判らないだろうと思うんですけど...
#s/したとき/したいとき/
#うーん、80桁ルールはまだ捨てられないなあ。
#自分は30inchでemacsを4x2に分割してますね. 横80くらいになるので. 8分割はframe移動が大変なのであんまよくないですが...
#しかしpythonで80桁ルールはきついですね...
#80桁で収まった方が読み易いのは間違いないので、その点は賛成です。好きでだらだら横に伸ばしてるわけじゃなくて、横方向を縮める努力を諦めた感じです。
#昔は意地でも収めようとしたけど
#aa,
#ああ、妥協することはあります。Common Lispも識別子が長くなってどうしようもなくなることがあるし。
#30インチ、見渡せる距離に置くと結構遠くなっちゃいそう。使ったことないので想像ですけど。でも画面が広いのはいいですよね。
#解像度では自分の環境は劣化してる。以前はnanao T960 で 1900x1400 位だったけど今は L997 を縦にして 1200x1600。 RT shiro: 昔は80桁でC-x3分割はしない、って方針だったんだけど、最近はスクリーンの横幅が
#自分にとって gauche が読み易い理由の一つは確実に 80 桁です。 RT shiro: うーん、80桁ルールはまだ捨てられないなあ。 http://bit.ly/9X0tLv #私のメインnotePCは横幅1440ピクセルあるので，最近は96桁2枚で使っているけど，自分で書くときは80桁におさまっている気がする．
#他社の作った既存の膨大な量のソースコードがすでに 80 どころか 120 くらいにしないと収まらないので、仕事だと桁数を縛るのはむずかしいですねぇ。でも個人的に Github に載せて人に見せることを前提に書いたりする場合は、横幅はできるだけ抑えますね。
Gauche > Archives > 2010/10/18