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

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> (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".

I think the aggressive merge simplification that gives "one simplest
explanation for the contents of the paths specified" is a wrong mode of
operation to use when you are filtering branches.  It might be a good
thing to support as an option, but I agree with you that it should not be
the default.

Perhaps --full-history is needed to the rev-list call (and the recent
invention --simplify-merges that will hopefully appear sometime after
1.6.0)?  See recent discussion of --full-history and the default merge
simplification between Linus and Roman Zippel.  I suspect that back when
the original cg-rewritehistory was written, not many people understood the
issues explained in that thread.