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)。然而，在查看 (3) 之后，它下降到第一个父级 (4)。这种行为是否明确？

4

2 回答 2

5

默认情况下，提交按时间倒序排列。您可以根据您传递的选项以不同的顺序获得输出。有关其他选项，请参阅git-rev-list手册页中的提交排序部分。

git log默认情况下也按时间倒序排列。但是，当您使用它运行它时--graph，意味着--topo-order.

最后，按日期提交排序是按提交日期完成的，但默认输出git log显示作者日期。使用补丁、精选和变基，这两者可能会不同步。

最后两点应该解释为什么您的两个输出的排序不同，以及为什么表面git rev-list上没有按日期排序。

于 2012-11-05T01:05:40.833 回答
2

这种行为是否明确？

在 Git 2.34（2021 年第 4 季度）中，修订遍历 API 已通过利用提交图（如果可用）来确定是否可以从任何现有 ref 访问提交，从而优化了修订遍历 API。

请参阅Patrick Steinhardt ( ) 的提交 f559d6d、提交 809ea28、提交 bf9c0cb、提交 f45022d（2021 年 8 月 9 日）和提交 29ef1f2（2021 年 8 月 5 日）。（由Junio C Hamano 合并 -- --在提交 a5619d4中，2021 年 9 月 3 日）pks-t
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'

请注意，并非所有 ref 对客户端都是可见的。

rev-list-options现在在其手册页中包含：

--unsorted-input

按照在命令行中给出的顺序显示提交，而不是按提交时间以相反的时间顺序对它们进行排序。不能与--no-walk或结合使用--no-walk=sorted。

rev-list-options现在在其手册页中包含：

不能与--graph. 不能与 --unsorted-inputifsorted或没有参数相结合。

2018 年：

Git 2.16（2018 年第一季度）将允许git describe在用作git describe <blob>. （在“哪个提交有这个 blob？
”中 查看更多信息）

在这种情况下， git rev-list 添加了一个新订单。
请参阅Stefan Beller ( )的提交 ce5b6f9。stefanbeller

revision.h: 按照提交的顺序引入 blob/tree walk

在遍历提交时按看到树对象的顺序列出树对象的功能将在下一个提交中使用，在这里我们git describe不仅要描述提交，还要描述 blob。

这意味着git rev-list手册页有一个新的对象遍历顺序：

--in-commit-order::

按提交的顺序打印树和 blob id。
树和 blob id 在提交首次引用后打印。

于 2017-12-29T20:40:51.600 回答