Re: [PATCH] revision: --ancestry-path

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 21, 2010, 08:01 UTC
Message-ID: <7vochdcjz5.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4BCEADA3.7090504@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

Show 11 quoted lines

> Am 4/21/2010 9:34, schrieb Johan Herland:
>> I can confirm that this patch works with my original (more complicated) 
>> scenario. I've also played around with combinations of --ancestry-path, --
>> graph and --parents (and even --boundary), and AFAICS, the new option does 
>> not clobber the other options, and (IMHO) it all behaves correctly in the 
>> scenarios I've tested.
>
> How about possible interactions with --reverse; --date-order/--topo-order,
> --parents (important for gitk); --simplify-by-decoration (useful for your
> problem that triggered this); --full-history and --simplify-merges with
> path limiting?

These are all good points.

I am reasonably sure that parents (specifically, "rewrite_parents") is broken. The new function should cull parents that do not appear on the ancestry path from merges (that is what "NEEDSWORK" is about). It may or may not break gitk, though---these off-path parents are shown as parents of an on-path merge but will be marked as UNINTERESTING.

I do not think reverse/date-order/topo-order would be affected by this change, as they only change the presentation order of what limit_list() returns;

Also simplify-merges and full-history should be Ok, as they control what is done in the current logic in limit_list(), which is an input to the new logic, meaning that the new logic will work on already simplified history.

This is not a new problem, but I strongly suspect that cherry-pick is broken the same way wrt "rewrite_parents".