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

Hi,

On Fri, 8 Aug 2008, Thomas Rast wrote:

Johannes Schindelin wrote:

quoted

On Fri, 8 Aug 2008, Thomas Rast wrote:

quoted

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

quoted

quoted

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.

And this is what I call wrong.  Simply dropping one side of the equation 
is not what I call "sane".

If you drop information, you are disagreeing with "content is king".

But hey, if other people agree with you, and this kind of thinking ends 
up in Git proper, I can still resort to other DVCSes.

Ciao,
Dscho