Re: [RFH] filter-branch: ancestor detection weirdness

From: Thomas Rast <trast@student.ethz.ch>
Date: Aug 8, 2008, 18:37 UTC
Message-ID: <200808082037.49918.trast@student.ethz.ch>
In-Reply-To: <alpine.DEB.1.00.0808081632580.24820@pacific.mpi-cbg.de.mpi-cbg.de>

Johannes Schindelin wrote:

Show 16 quoted lines

> On Fri, 8 Aug 2008, Thomas Rast wrote:
> 
> > I think a more careful use of rev-list -1 is actually a correct and easy 
> > way to figure out an ancestor.
> 
> I have not looked at your patch closely, or at your explanation, but I am 
> really certain that every attempt to replace the --boundary with a -1 must 
> fail.
> 
> Let me show you why I think that.  Just look at this history:
> 
> A - B - C
>   /
> D
> 
> Where all commits except B touch the inside directory.  Two options:

'rev-list' "solves" this problem for us. At the point where we are rewriting the branch pointers, commits have already been rewritten to whatever 'git rev-list --parents -- $subdir' told us to make them. I think there are only two cases for its output:

(a) Both A and D bring the same subdirectory contents.  'rev-list
    --parents -- $subdir' drops one side of the merge during pruning.
    It does not look past the merge to see whether the contents were
    arrived at via different changesets.  Thus the history becomes

      A' -- C'

D'

    and even that only if D was reachable by a different ref,
    otherwise D' is simply dropped.

(b) A and D bring different $subdir contents.  Then the merge is
    interesting and remains.  History is now

      A' -- B' -- C'
           /
      D' -/

Neither of those cases is a problem for the -1 strategy. A branch 'topic' pointing to B will be rewritten to (a) A' and (b) B'.

IOW, either the merge remains and there is no problem, or the side branches vanish too and there is no problem. rev-list never "forward simplifies" merges; it merely tries to prune away commits on the incoming side of the merge until all its parents are interesting.

Either that, or I missed something obvious. I think I'll have to come up with a better commit message...

- Thomas

-- 
Thomas Rast
trast@student.ethz.ch