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

> Johannes Schindelin wrote:
> > 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.