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

Junio C Hamano [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

Thomas Rast [off-list ref] writes:

quoted

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.