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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 19, 2012, 21:31 UTC
Message-ID: <7vd34vyoo1.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vhau7ypk6.fsf@alter.siamese.dyndns.org>

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

Show 11 quoted lines

> 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);

 (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.