Re: [PATCH 2/2] Fix ranges with git-show

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Thomas Rast <trast@student.ethz.ch> 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.