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

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

[Paul Mackerras]

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.

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

[Jon Seymour]

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.