Carlos Martín Nieto <cmn@xxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html