Re: [BUG] cherry-pick ignores some arguments

From: Junio C Hamano <gitster@pobox.com>
To: "Carlos Martín Nieto" <cmn@elego.de>
Cc: Yann Dirson <dirson@bertin.fr>, git list <git@vger.kernel.org>
Subject: Re: [BUG] cherry-pick ignores some arguments
Date: Fri, 15 Jun 2012 08:03:51 -0700	[thread overview]
Message-ID: <7vaa04d3c8.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1339691389.4625.9.camel@beez.lab.cmartin.tk> ("Carlos =?utf-8?Q?Mart=C3=ADn?= Nieto"'s message of "Thu, 14 Jun 2012 18:29:49 +0200")

Carlos Martín Nieto <cmn@elego.de> writes:

> On Thu, 2012-06-14 at 11:44 +0200, Yann Dirson wrote:
>> Hello list,
>> 
>> I just did a "git cherry-pick AAA BBB..CCC" using 1.7.10.3, and was surprised
>> that only the BBB..CCC range got picked - AAA was silently ignored.
>> 
>
> There is no way to know whether this is a bug without knowing how AAA,
> BBB and ccc are related? From the names, can we assume that AAA is a
> (grand)parent of BBB? If that is the case, cherry-pick is behaving as
> expected.

That is correct from the "rev-list" point of view.  The request is
telling us, by having BBB on the LHS of ".."  (which is the same as
saying "^BBB"), that nothing that is an ancestor of BBB should be
used, so if AAA happens to be behind BBB, it won't be picked.

In the context of "cherry-pick", "show", and "format-patch",
however, "I want AAA and things *between* BBB and CCC" is not an
unreasonable thing to ask [*1*].  You may be trying to port the
feature implemented on your 'master' branch by commits in the
consecutive range BBB..CCC to your 'maint' branch, but the
implementation may happen to depend on an unrelated fix AAA that
also is on your 'master' branch that came before BBB.

It's just that the existing "AAA BBB..CCC" syntax is *not* a way to
ask for that semantics, as it has an established "rev-list" meaning
you explained.  Obviously you could say

	git cherry-pick AAA $(git rev-list BBB..CCC)

to get that semantics, but it is a mouthful to say.

I am OK if somebody comes up with a different syntax to allow users
to say "I have multiple range expressions. Please grab sets of
commits from them *separately*, and give me a *union* of them".

It is OK to add such a feature---it will have to be a lot more
expensive from latency point of view (i.e. such a query cannot
stream and always have to be "limited" in rev-list sense)---as long
as such a change will not hurt performance and semantics of simpler
cases.

[Footnote]

*1* I've said this a few times here, but the way "show --do-walk"
walks the history is an ugly hack that merely happens to appear to
work sometimes but is done in a wrong way.