Re: rev-list --parents --full-history + path: something's fishy

From: Johannes Sixt <johannes.sixt@telecom.at>
Date: May 25, 2008, 12:26 UTC
Message-ID: <200805251426.54755.johannes.sixt@telecom.at>
In-Reply-To: <alpine.LFD.1.10.0805241817500.3081@woody.linux-foundation.org>

On Sunday 25 May 2008 03:21, Linus Torvalds wrote:

Show 21 quoted lines

> On Sat, 24 May 2008, Johannes Sixt wrote:
> > but this does not:
> >
> > $ git rev-list --full-history --parents HEAD -- a
> > M A B
> > B A
> > A
>
> That is the "correct" output.
>
> That's what "--full-history" means: do not simplify merges away when all
> the data comes from just one branch (in this case from "B").
>
> So it shows you commit 'M' because you asked for full-history.
>
> Commit 'M' has parents 'C' and 'B', but since 'C' doesn't actually modify
> the file at all, the regular commit simplification will simplify 'C' away,
> so now that parent 'C' will become 'A'. So 'M' has the _simplified_
> parent's 'A' and 'B'.
>
> Then it shows 'B' (parent 'A') and 'A' (no parent).

The history was this:

   C--M
  /  /
 A--B

Now assume that both B and C change a, but so that it is identical in both B and C. I thought that --full-history makes a difference *only* for this case, because without --full-history the revision walk would choose either B or C (not quite at random, but in an unspecified manner), but not both; but with --full-history the revision walk would go both paths.

This makes a difference in git-filter-branch --subdirectory-filter: We do want to simplify history to those commits that touch a path, but we don't want to simplify away the case outlined in the previous paragraph.

Show 12 quoted lines

> > Of course, I'd expected to see this:
> >
> > $ git rev-list --full-history --parents HEAD -- a
> > B A
> > A
>
> Why did you ask for --full-history, if you're not interested in merges
> that are irrelevant? To get what you wanted, just do
>
> 	git rev-list --parents HEAD -- a
>
> and it should give you exactly that output.

In the case at hand this would be sufficient, but in git-filter-branch we don't want to prune branches whose modifications to a path make the path identical.

What shall we do in git-filter-branch --subdirectory-filter?

-- Hannes