record cherry-pick merges

Basically, this is asking for cherry-pick support. Being able to merge a single revision and have it marked as merged, even though its parents are not merged.

At present, only Arch and darcs support this. monotone, hg, git, (svk?) do not. In most of these systems it isn't clear how to do this.

There is already a spec for this:
http://bazaar-vcs.org/Specs/RecordCherryPick
and
https://features.launchpad.net/products/bzr/+spec/record-cherrypick-data

I'm pretty sure git does support this ...

On Fri, 2007-07-27 at 11:29 +0000, Colin Watson wrote:
> I'm pretty sure git does support this ...

Last I looked at the git revision format, it only supported transitive
node references, and for this you need intransitive references of some
form. So I'd like to see how - a series of commands to get it to jump
would be enough for me to test with.

-Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

It would be nice to have a reference to the revision(s) of the branch that where cherry-picked; not just the copied information of the cherry-picked revisions.

This will allow gui's to indicate the origins of certain cherry-picked revisions.

Subversion supports this now :)

Can you provide a link to their docs on it?

Thanks,
Rob

http://subversion.tigris.org/merge-tracking/func-spec.html
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html

The implementation in subversion is very poor and should probably not be used for anything, except an example of how not to do it. Though they claimed to improve it in 1.6 (haven't tried that version).

Just recording the original revision information would be fine IMO, so that later merges know it's been merged already. git is probably a better inspiration.

You mean merging revisions before/after in separate batches? I'm not sure there is any other way to do it, seeing as removing a revision from the patchset could break revisions after it creating pre-merge conflicts. Regardless, any working implementation (and Subversion's method does seem to work, at least) is better than none. Recording the information needed for down the road would at least allow me to finish my Subversion --> Bazaar import (in this regard), so that would be appreciated too. git does not support cherry-pick tracking yet.

Git supports recording cherrypicks of full revisions, and puts the metadata in the commit message.

Another possibility wrt merging: Throw an error if a merge would include cherry-picked revisions, saying something like "Cannot merge revision 54 to 202: Revision 99 is already merged. First, merge up to revision 98."

To make this smoother, Bazaar could also support doing multiple merges in a single commit.

Wouldn't that require tracking of cherry-picks? Otherwise we wouldn't be able to tell that a particular revision was already merged in the first place.

Of course; that's the whole point of this bug... :p