Re: git-rev-list problem with --max-age and --merge-order
- From
Jon Seymour <jon.seymour@gmail.com>
- Date
- Jun 16, 2005, 16:06 UTC
- Message-ID
- <2cfc4032050616090632f10b2e@mail.gmail.com>
- In-Reply-To
- <2cfc40320506160745411858f1@mail.gmail.com>
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.