record cherry-pick merges

Bug #67174 reported by Ted Jordan on 2006-10-20
This bug affects 21 people
Affects Status Importance Assigned to Milestone
Bazaar Git Plugin
Bazaar Subversion Plugin
Declined for 0.1 by Jelmer Vernooij
Declined for 0.2 by Jelmer Vernooij
Declined for 0.3 by Jelmer Vernooij
Declined for 0.4 by Jelmer Vernooij
Declined for 0.5 by Jelmer Vernooij
Declined for 0.6 by Jelmer Vernooij
Declined for 1.0 by Jelmer Vernooij
Declined for 1.1 by Jelmer Vernooij
Declined for 2.0 by Jelmer Vernooij
bzr (Debian)

Bug Description

- Create several revisions in a child branch.
- Merge one of the later revisions from the child branch into a parent branch. Making sure to skip at least one revision from the child branch. So for example if the child branch has revisions 1 and 2, you would merge in revision 2 thus skipping revision 1.
- Commit the merge in the parent branch.
- Run 'bzr missing' in the parent branch on the child branch.
- This will say the parent branch is missing the revision that was just merged in and commited.

Running 'bzr log' on the parent branch will also not show the merged revision from the child branch.

John A Meinel (jameinel) wrote :

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:

Changed in bzr:
importance: Undecided → Wishlist
status: Unconfirmed → Confirmed
Colin Watson (cjwatson) wrote :

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.


GPG key available at: <>.

Martin Pool (mbp) on 2009-07-03
summary: - Selective merging is not reflected through bzr missing
+ [master] record cherry-pick merges
Changed in bzr:
importance: Wishlist → Medium

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.

Luke-Jr (luke-jr) wrote :

Subversion supports this now :)

Can you provide a link to their docs on it?


Per Johansson (per.j) wrote :

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.

Luke-Jr (luke-jr) wrote :

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.

Jelmer Vernooij (jelmer) wrote :

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

Jelmer Vernooij (jelmer) on 2010-06-13
Changed in bzr-svn:
status: New → Triaged
importance: Undecided → Wishlist
Luke-Jr (luke-jr) wrote :

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.

Jelmer Vernooij (jelmer) wrote :

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.

Luke-Jr (luke-jr) wrote :

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

Jelmer Vernooij (jelmer) on 2010-07-30
summary: - [master] record cherry-pick merges
+ record cherry-pick merges
Changed in bzr-git:
status: New → Triaged
importance: Undecided → Wishlist
Jelmer Vernooij (jelmer) on 2011-02-01
tags: added: cherrypick merge
Changed in bzr (Debian):
status: Unknown → Confirmed
Jelmer Vernooij (jelmer) on 2017-06-23
Changed in brz:
status: New → Triaged
importance: Undecided → Wishlist
Jelmer Vernooij (jelmer) on 2018-03-06
Changed in brz-git:
status: New → Triaged
importance: Undecided → Wishlist
Jelmer Vernooij (jelmer) on 2018-05-10
no longer affects: brz-git
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.