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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 12, 2008, 21:33 UTC
Message-ID: <7v7ialrk9a.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <200808091200.21634.trast@student.ethz.ch>

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

Show 6 quoted lines

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