Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
Re: [git pull] drm-next Linus Torvalds Sun, 29 Mar 2009 14:48:18 -0700 (訳注 : Daveのrebaseのやり方が好みでないというLinusに対して) > 2009年5月29日(日曜日) Dave Airlieの発言 > > 今から自分がしようとしているのは、直線じゃないツリーを送ろうとしているだけだ。 > パッチを自分の次のツリーにマージする時はいつでも、そこにそれがあるからだ。 > 自分は、Ericのツリーを自分のツリーに直接プルして、その結果を送ろうとしている。 > きれいなマージ履歴について注意しているとは思っているけど、前に言ったように、 > カーネルツリーに関してのドキュメントが何もない状態では、君がどうしたいのか > 本当のところは今の今まで分からないよ。 自分が求めているのは、きれいな履歴だ。でも、それ
Git の挙動に変なところを見つけたので、パッチを作って Git のメーリングリストに投げてみたところ、何度かのレビューを経て、無事に取り込まれた。 Git に貢献したい人とか、オープンソース開発の流れに興味がある人もいるだろうから、作業の流れを書いておくことにする。 1. バグを発見する 何はともあれ、修正したいところを見つけるところから。 先日、git difftool --dir-diff が便利すぎて泣きそうです という記事を書いたが、difftool --dir-diff の挙動を調べているうちに、一時ファイル書き戻し条件が変なことに気づいた。 手元のバージョンが古いのかとも思ったが、master ブランチでも再現したので、ちょっくら深入りしてみた。git difftool は Perl スクリプトだったので、ソースコードに print を追加しつつ挙動を探っていった。しばらく調
今やソースコード管理システムの標準となっている「Git」（関連記事）。作者のLinus Torvalds氏から指名され、メンテナーとして責任を負っているのが現在米国のGoogle本社に勤務する濱野純氏だ。濱野氏に、メンテナーを引き継いだ経緯、Googleでの仕事などについて聞いた。 Gitコミュニティはどのように活動しているのですか。 本体の開発は、デザインからコードレビューまで、すべてGitメーリングリストで行っています。最近のリリースには、それぞれ60人から80人程による変更が入っていますが、常に活動している主要な開発コミュニティ参加者、と言えるのは10人程度です。 開発者でない人たちで#git IRCチャネルとか、stackoverflowなどでエンドユーザーのサポートをしてくれる人たちの数はもっと多いと思います。この人たちも、Gitコミュニティの重要な仲間です。 Gitコミュニティ
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
I have a Git repository which contains a number of subdirectories. Now I have found that one of the subdirectories is unrelated to the other and should be detached to a separate repository. How can I do this while keeping the history of the files within the subdirectory? I guess I could make a clone and remove the unwanted parts of each clone, but I suppose this would give me the complete tree whe
問題 git submodule で他のリポジトリ(以下「サブモジュール」)の内容を埋め込むことが簡単にできるのですが、 ごく稀に追加したサブモジュールを削除したくなる場合があります。 サブモジュールの追加や更新は git submodule add や git submodule update で簡単にできるものの、 何故か git submodule rm サブコマンドはありません。 どうすれば削除できるのでしょうか。 解決方法 submodule_name='The name of a submodule you want to remove.' submodule_path="$(git config --file .gitmodules --get "submodule.$submodule_name.path")" git rm --cached "$submodule_pat
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
についてのメモ。 出力件数を指定する 出力件数を表示する。どちらもいっしょ。 $ git log -n 10 # 最新10件のログ $ git log -10 # 最新10件のログ 範囲指定 コミットの範囲を指定する $ git log HEAD~10..HEAD~5 # 10個前か5個前までのログ $ git log HEAD~10.. # 10個前から最新までのログ $ git log 3hg4390fj3..93jj23rn20 # ハッシュ値で範囲指定 パッチ形式で出力する -pでパッチ形式で出力する。 $ git log -p Authorから探す コミットした人を指定する。部分一致っぽい。 $ git log --author=hokamura # hokamuraを含むAuthorのログ コミット日時から探す 指定した時間以降のコミットを表示する。どちらもいっしょ。 $ gi
私がgitを使いだしたのはgit入門(濱野2009)を読んでからなんですが、これが非常によかった。何のために用意された機能なのか/どのような仕組みで動いているのか、その根っこのところがきちんと解説されているので各種コマンドがどのような意味を持つのかすんなり理解できた。分散VCSは複雑そうで敬遠していたのだが、gitは構造がシンプルで直感的なので原理さえ理解すればsvnより容易に使いこなせる(というかsvnのアーキテクチャについてはいまだに理解できてない……。どこかにいい入門書ないだろうか)。 gitのアーキテクチャについて、自分なりの理解をまとめてみようと思う。 gitはどのようにリポジトリを管理しているか オブジェクトとは、gitがデータを扱う単位。コミット、ファイルの内容などはオブジェクトとして表される オブジェクトは内容に応じた一意のIDを持つ(内容のハッシュ値がIDになる) 一回の
動機 複数のremoteを設定したリポジトリがある。 $ git remote origin library-agit fetchのデフォルトだとタグも取得する。ところでタグの名前空間はどこからfetchするかによらず同じだ $ git tag my_tag $ git fetch library-a # library-aのタグが取得されrefs/tags/*へ $ git tag v1.0 v2.0 v2.1 v2.2 : : my_tagノーグッド。わかりにくいし、リモートが多数になると衝突しかねない。タグの名前空間を分けたい。 library-aのタグは library-a/v1.0 とかでアクセスできるようになるといいですね。 方法 git fetchに--no-tagsオプションを付けることでタグを取得しないことができる $ git fetch --no-tags librar
やりたいこと ReopA,RepoBがある。ReboB/masterをRepoA/repob-branchにコピーしたい 方法 追記: git fetch location refs/heads/branch-from:refs/heads/branch-to でいける、とJunio様に教えていただきました(ひー)。コメント参照。 各リポジトリの位置を/repo_a,/repo_bとする 1. RepoBのオブジェクトを全部RepoAにコピー。 $ cp -rf /repo_b/.git/objects /repo_a/.git/2. RepoB/masterのオブジェクトIDを調べる [/repo_b]$ cat .git/refs/heads/master 37e7c1e20928bc...3. 2で調べたコミットオブジェクトをチェックアウトする [/repo_a]$ git chec
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く