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