Re: [BUG] cherry-pick ignores some arguments
- From
- Yann Dirson <dirson@bertin.fr>
- Date
- Jun 15, 2012, 07:14 UTC
- Message-ID
- <20120615091425.20e40af9@chalon.bertin.fr>
- In-Reply-To
- <1339691389.4625.9.camel@beez.lab.cmartin.tk>
On Thu, 14 Jun 2012 18:29:49 +0200 Carlos Martín Nieto <cmn@elego.de> wrote:
Show 16 quoted lines
> 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. > > See the DESCRIPTION in http://git-scm.com/docs/git-rev-list for further > explanation, but the short of the story is that the second argument told > it to ignore any commit before BBB, so AAA is not in the list of commits > to be applied.
OK, this is exactly the case. Looking back at the cherry-pick manpage, I'd say that what confused me is the implicit --no-walk: the standard "git cherry-pick AAA" does not look like a rev-list spec at all!
At least for this command, it would seem more natural (to me at least) to take each arg one by one and feed it to "rev-list --no-walk" or similar. Maybe some special rev-list flag could trigger such a particular behaviour, pretty much like what --no-walk does ?
Another orthogonal UI issue I see, is that rev-list could be more user-friendly to warn the user when one element of a rev list is ignored because of another one. Not sure whether this would be useful for all explicit rev lists specified by the user - maybe a config var and associated option would be needed too.
-- Yann Dirson - Bertin Technologies