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

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

Thomas Rast <trast@student.ethz.ch> writes:

> Johannes Schindelin wrote:
>> 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.
>
> BTW, the following is fairly ironic.  (It was later rewritten in
> 813b473 to the current one-shot 'rev-list --parents' form.)

Hmm, Dscho, perhaps we should take Thomas's patch as a "revert to 685ef54
to fix breakage introduced by 813b473", and demonstrate the breakage with
one of the new tests in his series?

I think it is Ok to use the "view --parents for all branches, instead of
looping with -1" approach when there is no path limiter, and that might be
faster, but if it complicates the logic too much, it probably is not worth
it.  I also _suspect_ that if you use --simplify-merges, the optimization
made by 813b473 would still be usable even with path limiter.

By the way, I am not sure if using --simplify-merges unconditionally is
necessarily a good thing to do.

The user who filters the branches may be interested in a full history
(where using --simplify-merges is the right thing to do), or may be
interested in getting one simplest possible explanation of the end result,
similar to what you get from rev-list without the option.