Re: [BUG] multi-commit cherry-pick messes up the order of commits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jonathan Nieder <jrnieder@xxxxxxxxx> writes:

> Yes, exactly.  Another question: what should
>
> 	git cherry-pick master..next maint..master
>
> do?

Revision ranges are not defined as a union of sets, but a single set as a
range between zero or more bottom (UNINTERESTING) commits and zero or more
top commits, the ones reachable from the top but not from the bottom, so
the above will work as if you said "^master ^maint master next", which is
the same as "master..next" (if you assume all of "maint" is contained in
"master" all of which is contained in "next", of course).

And it is not likely to change soon.

In the longer term (or in an alternate universe where we were inventing
Git from scratch today without any existing users), we may want to revamp
the revision machinery, taking advantage of the recent addition of the
"cmdline" facility to it, so that we would walk ranges "master..next" and
"maint..master" independently, clearing the object flags as needed between
the separate traversals as needed, and then take a union of these ranges,
before returning results from get_revision() calls.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]