Junio C Hamano <gitster@xxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Thomas Rast <trast@xxxxxxxxxxxxxxx> writes: >> >>> As explained in the previous commit, git-show's DWIM walking mode >>> fails with ranges where propagating the UNINTERESTING marks is needed >>> for correctness. >> >> Finally ;-) >> >> Another bad thing about the Linus's walking hackery is it depends on >> the order of parameters (e.g "show maint master..next" and "show >> master..next maint" gives us vastly different results). > > By the way, this reminds me of a totally separate topic we discussed > here recently. > > Imagine you were on the maint-1.7.9 branch and gave this command. > > git cherry-pick maint master..topic > > The range makes the command walk, and because of that, the above > does not result in transplanting a topic that depends on the commit > at the tip of maint to an older maint-1.7.9 branch. You would > instead need to write something like: > > git cherry-pick maint $(git rev-list --reverse master..topic) > > to prevent cherry-pick from walking. > > But we could introduce a new "mode" to the revision machinery so > that a single token on the command line is parsed as a set of > commits, and causes the "walking" machinery not to walk the commits > in the union of the sets of commits specified from the command line, > e.g. (pardon my terrible option name) > > git cherry-pick --union-no-walk maint master..topic1 master..topic2 > > which would instruct the revision machinery that: > > (1) "maint" (the first token) yields a set that consists of a > single commit at the tip of "maint"; > > (2) "master..topic1" (another token) yields a separate set that > consists of commits on the "topic1" branch since it forked from > the "master" (similarly for "topic2"); > > (3) the revision machinery is to compute these two sets > _independently_ (meaning, object flags like UNINTERESTING are > cleared after each run); Sorry, s/two sets/three sets/; I originally wrote without "topic2" and forgot to clean it up. > (4) take union of the set, eliminating duplication (if "topic1" and > "topic2" share some commits at their bottom, they are > de-duped); and > > (5) the call to get_revision() will not walk, and instead return > the elements of the resulting union one-by-one. > > which would give us what most users of cherry-pick would naturally > expect. For some commands (like cherry-pick and show), we might > even want default to --union-no-walk behaviour, but that is probably > a Git 2.0 topic after we gain enough confidence with experience. -- 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