Thread (2 messages) flat view 2 messages, 2 authors, 2019-05-20

Re: Revision walking, commit dates, slop

From: Jakub Narebski <hidden>
Date: 2019-05-20 11:02:41

Derrick Stolee [off-list ref] writes:
On 5/18/2019 12:17 AM, Mike Hommey wrote:
quoted
On Sat, May 18, 2019 at 12:58:28PM +0900, Mike Hommey wrote:
quoted
On Sat, May 18, 2019 at 03:50:05AM +0200, SZEDER Gábor wrote:
quoted
All the above is without commit-graph, I presume?  If so, then you
should give it a try, as it might bring immediate help in your
pathological repo.  With 5k commit in the same second (enforced via
'export GIT_COMMITTER_DATE=$(date); for i in {1..5000} ...') I get:

  $ best-of-five -q git rev-list HEAD~..HEAD
  0.069
  $ git commit-graph write --reachableComputing commit graph generation
  numbers: 100% (5000/5000), done.
  $ best-of-five -q git rev-list HEAD~..HEAD
  0.004
I'm not observing any difference from using commit-graph, whether in
time or in the number of commits that are looked at in limit_list().
-c core.commitGraph=true does make a difference in time, but not in the
number of commits looked at in limit_list(). So it's only faster because
each iteration of the loop is faster. It means it's still dependent on
the depth of the dag, and the larger the repo will grow, the slower it
will get.
The plan is to use the commit-graph's generation numbers for these A..B
queries, but due to some cases when commit date is a _better_ heuristic
than generation numbers, we have not enabled them for A..B. You'll see
that 'git rev-list --topo-order -n 1 HEAD` will be much faster with the
commit-graph, but adding '--topo-order' to your 'HEAD~1..HEAD' query
should not change the time at all.

See [1] for the discussion about "generation number v2" which will allow
us to use a better heuristic in these cases.

[1] https://public-inbox.org/git/6367e30a-1b3a-4fe9-611b-d931f51effef@gmail.com/
Are there any blockers that prevent the switch to this
"generation number v2"?

- Is it a problem with insufficient data to choose the correct numbering
  as "generation number v2' (there can be only one)?
- Is it a problem with selected "generation number v2" being
  incompatibile with gen v2, and Git failing when new version of
  commit-graph is used instead of softly just not using commit-graph?
- Or is it something else?

Best,
--
Jakub Narębski
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help