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

[Thomas Rast <trast@student.ethz.ch>]

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

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.

(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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]