6

git-rev-list は、返されるコミットをどのように順序付けますか?

私は主に、開発の並行ブランチで行われ、その後メイン ブランチにマージされるコミットについて言及しています。コミットは日付順に並べられているようには見えませんが、コミットは過去または将来のさまざまな時点から選択できるため、これは理にかなっています。

たとえば、ここにいくつかの歴史がありgit-logます...

*   Sat, 25 Aug 2012 11:37:23 -0700 8238401
|\  
| * Thu, 23 Aug 2012 12:29:09 -0700 c9de861
* |   Fri, 24 Aug 2012 16:29:01 -0700 b7e8827
|\ \  
| * | Mon, 14 May 2012 20:46:30 +0200 0a1db74
| * | Mon, 14 May 2012 17:54:25 +0200 e03e71d
| * | Fri, 13 Jul 2012 12:01:11 +0200 bffa852
* | |   Fri, 24 Aug 2012 15:45:13 -0700 09fad50
|\ \ \  
| * | | Fri, 24 Aug 2012 12:19:22 -0700 97a17e4
| * | | Thu, 9 Aug 2012 19:43:25 -0700 5f4a61a
| * | | Fri, 3 Aug 2012 14:28:07 -0700 0c8858d
| * | | Thu, 2 Aug 2012 13:00:58 -0700 aa13bf0
| * | | Wed, 18 Jul 2012 14:30:15 -0700 decff7b
* | | |   Fri, 24 Aug 2012 15:43:19 -0700 091c742

これは、rev-list による同じ履歴の出力です。

$ git rev-list HEAD --max-count=13
8238401ccb9f7018c927866896bea583d351ad2a # 1 root
c9de8611d6a3e77757a714cdf6acf46178b1d622 # 2 descends into the second parent
b7e8827b8bbca0c69d85be34cc4a88888c1152f2 # 3 first parent of root
09fad5069636fb2e8cacf15817834e3d32ff6b8e # 4 descends into the first parent
091c742af985cc78711727ca06a24ae42b376fae
7fbca880aa5c011257ef734d0b5bfd5545dbaf6b
07c06f7a83640e11d6be13a87f02e986ecc6e4b3
1168410426293aef8ce33becb277ff225595e183
97a17e4e9fa5cafa531ff79cb88a9ee5c224a613
0a1db746fbcaf09681e446250f75581cc8f8fd05
e03e71da56608f60770eb80767dcd94e698cdcae
5f4a61aea834fe25ce1596bc9c0e0b5e563aa98b
0c8858de8c82bae3fd88513724689a07d231da7e

rev-list コマンドは、最初の親をリストするか、n 番目の親のコミット グラフに降りるかをどのように決定しますか? たとえば、上記の (1) を見た後、rev-list は 2 番目の親 (2) に降りてきます。ただし、(3) を見た後、最初の親 (4) に降りてきます。この動作は明確に定義されていますか?

4

2 に答える 2

5

デフォルトでは、コミットは時系列の逆順に並べられます。渡すオプションに応じて、異なる順序で出力を取得できます。その他のオプションについては、 git-rev-listの man ページのCommit Orderingセクションを参照してください。

git logデフォルトでは、時系列の逆順でも注文できます。--graphただし、それを実行すると、--topo-order.

最後に、日付によるコミットの順序付けはコミット日によって行われますが、デフォルトの出力では作成者git logの日付が表示されます。パッチ、チェリー ピック、およびリベースを使用すると、これら 2 つが同期しなくなる可能性があります。

これらの最後の 2 つのポイントは、2 つの出力の順序が異なる理由と、表面上git rev-listは日付順に並べられていない理由を説明する必要があります。

于 2012-11-05T01:05:40.833 に答える
2

この動作は明確に定義されていますか?

Git 2.34 (2021 年第 4 四半期) では、リビジョン トラバーサル API が最適化され、利用可能な場合はコミットグラフを利用して、既存の参照からコミットに到達できるかどうかを判断します。

コミット f559d6d、コミット809ea28、コミット bf9c0cb、コミット f45022d (2021 年 8 月 9 日)、およびコミット 29ef1f2 (2021 年 8 月 5 日) by Patrick Steinhardt ( pks-t)を参照してください。
( 2021 年 9 月 3 日にコミット a5619d4でJunio C Hamanoによってマージされました)gitster

connected: 入力リビジョンをソートしません

署名者: Patrick Steinhardt

一連のヒントから到達可能なオブジェクトがすべて接続されているかどうかを計算するために、これらのヒントを正の参照および としてリビジョン ウォークを実行します--not --all。
--not --allリビジョン ウォークは、既存のすべての参照を興味のないものとしてロードします。これは、多くの参照を持つリポジトリでは非常に高価になる可能性があります。

コマンドのベンチマークを行うgit-rev-listと、入力リビジョンの初期ソートが最もコストのかかる単一フェーズであることがわかります。すべての参照がロードされた後、最初にコミットを作成者の日付でソートします。
約 220 万の参照がある実際のリポジトリでは、git-rev-list.

最終的に、接続チェックは、入力リビジョンの順序をまったく気にするべきではありません。
カットオフ ポイントに到達するまで、すべてのオブジェクトを実際に歩けるかどうかだけが問題です。
したがって、入力をソートするのは完全に時間の無駄です。

新しい " --unsorted-input" フラグを導入するgit-rev-listと、コミットがソートされなくなり、接続チェックが常にフラグを通過するように調整されます。
これにより、 のクローンで実行される次の高速化が実現しますgitlab-org/gitlab。

Benchmark #1: git rev-list  --objects --quiet --not --all --not $(cat newrev)
  Time (mean ± σ):      7.639 s ±  0.065 s    [User: 7.304 s, System: 0.335 s]
  Range (min … max):    7.543 s …  7.742 s    10 runs

Benchmark #2: git rev-list --unsorted-input --objects --quiet --not --all --not $newrev
  Time (mean ± σ):      4.995 s ±  0.044 s    [User: 4.657 s, System: 0.337 s]
  Range (min … max):    4.909 s …  5.048 s    10 runs

Summary
  'git rev-list --unsorted-input --objects --quiet --not --all --not $(cat newrev)' ran
    1.53 ± 0.02 times faster than 'git rev-list  --objects --quiet --not --all --not $newrev'

すべての参照がクライアントに表示されるわけではないことに注意してください。

rev-list-optionsmanページに含まれるようになりました：

--unsorted-input

コミット時間の新しい順に並べ替えるのではなく、コマンド ラインで指定された順序でコミットを表示します。--no-walkまたはと組み合わせることはできません--no-walk=sorted。

rev-list-optionsmanページに含まれるようになりました：

との併用はできません--graph。引数が指定されていない--unsorted-input場合、または指定されていない場合と組み合わせることはできません 。sorted

2018:

Git 2.16 (2018 年第 1 四半期) ではgit describe、git describe <blob>.
(詳細については、「どのコミットがこの blob を持っていますか?」を参照してください) 。

そのコンテキストでは、git rev-list は新しい順序を追加します。Stefan Beller ( )によるコミット ce5b6f9
を 参照してください。stefanbeller

revision.h: コミットの順序でブロブ/ツリー ウォーキングを導入する

コミットのトラバース中に表示された順序でツリー オブジェクトを一覧表示する機能は、次のコミットの 1 つで使用されます。ここでは、git describeコミットだけでなく BLOB についても説明するように教えています。

これは、git rev-listマニュアル ページに新しいオブジェクト トラバーサル順序があることを意味します。

--in-commit-order::

ツリーと BLOB の ID をコミット順に出力します。
ツリーと BLOB の ID は、コミットによって最初に参照された後に出力されます。

于 2017-12-29T20:40:51.600 に答える