threads / discuss / 960

git-rev-list problem with --max-age and --merge-order

Subject: git-rev-list problem with --max-age and --merge-order

## tl;dr

2 messages between Jun 16, 2005 and Jun 16, 2005.

replies: 1people: 2as markdown or json

Paul Mackerras· Jun 16, 2005, 12:39 UTC · lore

I have a version of gitk that draws stuff more-or-less as it receives it from git-rev-list -- it reorders the commits somewhat but it doesn't need to wait for the end of the output from git-rev-list before it can draw anything. To do that it passes --merge-order to git-rev-list and relies on the property that parents will be listed after all of their children.

I also want to make the default be to show the commits for the last 30 days. However, using --max-age with --merge-order outputs many fewer commits than I get if I use the same --max-age argument without --merge-order. For example, on the current linux-2.6 git tree, git-rev-tree --max-age=1116330140 HEAD outputs 655 commits, whereas git-rev-tree --merge-order --max-age=1116330140 HEAD only outputs 173 commits. That date is 2005-05-17 21:42:20 in my timezone, about 30 days ago. An example of a commit that isn't output with --merge-order is 1e86d1c648508fd50e6c9960576b87906a7906ad:

Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>  2005-06-02 14:11:37
Committer: Linus Torvalds <torvalds@ppc970.osdl.org>  2005-06-03 01:19:27
[PATCH] ppc64: Fix result code handling in prom_init

Any ideas why using --merge-order means we don't see this one? It's certainly less than 30 days old.

Thanks, Paul.

Jon Seymour· Jun 16, 2005, 16:06 UTC · lore

Re: git-rev-list problem with --max-age and --merge-order

G'day Paul,

I think I know why this is happening and I think it has a relatively trivial fix, but I need to confirm this tomorrow after the effects of several schooners of Toohey's Old have worn off.

The current logic is to stop after one commit is found with an age greater than the maximum age. This doesn't work as expected if a "right" branch has an "old" commit since, by being a right branch, this commit will appear at the start of the merge-order list and the output of any commits in the left branch will be suppressed by this logic.

I think the --merge-order logic should be altered as follows:
    - stop at the first epoch boundary with an age greater than the maximum age 
      but filter out (from display) any commits older than the maximum
age prior to that boundary.

This will still omit commits in the case that either the epoch boundary or a commit beyond the epoch boundary have timestamps that don't match the merge order, but that should be a relatively infrequent occurrence.

I'll create a patch for the current Linus HEAD later today.
jon.

← back to recent threads