Git で管理してるレポジトリーで、いくつかのブランチを別々の場所にチェックアウトしたいことがある。 たとえば GUI なツールでブランチ間の比較したい 同時に実行して比較しつつテストしたい ブランチ間でファイルをコピーしたい ドキュメントの生成結果を別ブランチで管理したい といったときに、必要になる。 ブランチの個数だけ clone しちゃえば用は足りそうなんだけど、でかいレポジトリーだったら時間もディスク容量ももったいない。 git-new-workdir を使うべきでしょう！ 先日、「git-new-workdir を使えばワーキング ディレクトリーを複数を作れて便利」と書いてあるブログを読んだ。 git-new-workdir が便利 - #生存戦略 、それは - subtech git-new-workdir の usage を見てたら、別ブランチのワーキング ディレクトリー作成
I have my text editor to automatically trim trailing whitespace upon saving a file, and I am contributing to an open source project that has severe problems with trailing whitespace. Every time I try to submit a patch I must first ignore all whitespace-only changes by hand, to choose only the relevant information. Not only that, but when I run git rebase I usually run into several problems because
CodeRepos から GitHub に移行するパターンで，両方のレポジトリでユーザ名が同じでも，結局別人扱いされてしまうのでどうしたもんかなぁと思っていたのだけど，こことかこことか見るとマッピングファイルを作ればいいということがわかった． git help svn すると -A(--authors-file) というオプションがあって，これに次のフォーマットでマッピングを記述しておいて読ませるらしい． loginname = Joe User <[email protected]>loginname には svn での名前を書いておけばいい．行区切りで複数のマッピングを書ける． さらに svn.authorsfile という config にファイル指定しておけば良さげだったので，git config --global で登録してみた．これで git svn の度に -A しなくていい．
前回の続き。 前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。 で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えてお
この記事は Git Advent Calendar 6日目の記事です！ Git submodule って最初わかりにくいと思うので、基本的な説明をしようと思います。 git submodule とは git submodule は、外部の git リポジトリを、自分の git リポジトリのサブディレクトリとして登録し、特定の commit を参照する仕組みです。 Subversion でいうところの、external と似ています。 さて、解説のため、手元に、リポジトリA (/path/to/a) とAの submodule として、よく使う例として Bootstrap (元Twitter Bootstrap) を登録してみます。 git submodule を理解するうえで重要なのは、 リポジトリAが指し示すsubmoduleとしてのBootstrapのcommit 現在のBootstr
2012年09月27日 初めてのパッチ投稿(体験談) 2012年9月20日に行われたテクニカルジャンボリーでパッチ投稿について話をしてきました。 ここにそのスライドとビデオを貼っておきます。 Patch101 from Tetsuyuki Kobayashi メイルソフト"Thunderbird" というべきところで間違って"Firefox"と言ってしまっているところが多々ありました。 参考情報 git send-email で エイリアスを使う パッチを投稿するときのgitコマンド Debian でgit-emailでGmail経由でメール送信する方法 「Linux」カテゴリの最新記事 タグ ： celfjp linux embedded patch
社内向けに「こわくない Git」というタイトルのスライドを作って発表しました。 対象者は「マージがなんとなく怖い」「エラーが怖い」「リベース使うなって言われて怖い」と、Git が怖いと思っている人です！ こわくない Git from Kota Saito 発表中に出た質問など 補足も兼ねて、上のスライドを発表した際に出た質疑応答などをここに書いておきます。 Q: 常に Non Fast-Forward (--no-ff) でいいのでは、と思えるけど git merge がデフォルトだと Fast-Foward or Non Fast-Forward (--ff) なのはなぜ？ A1: Non Fast-Forward だと、確かにメリットが多いのですが、1点だけデメリットがあります。特に差分が無い状態で git merge --no-ff すると、空のマージコミットが作られてしまうのです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
