bzr-rebase loses merges

[Alexey Borzenkov]

The attached script shows the problem. When you rebase and you have merges in your tree, they disappear. If you use --always-rebase-merges then the commit will show up in history, but it will be completely empty. Thus bzr-rebase currently loses merges completely.

[Jelmer Vernooij (jelmer)]

  status triaged
  importance high
--
Jelmer Vernooij <email address hidden> - http://samba.org/~jelmer/
Jabber: <email address hidden>

[Max Bowsher (maxb)]

I'm working on this ... Robert's fix is a step in the right direction but there is quite a bit more to do.

First, the current code explicitly only rebases a left-most path, which AFAICS is just completely wrong.

Second, the parent selection logic needs to be rewritten.

Intertwined with that, there's the conundrum of --always-rebase-merges - a behaviour I would make default and mandatory, since the opposite has the potential to discard desired changes made as part of conflict resolution.

[Jelmer Vernooij (jelmer)]

On Sun, 2009-11-15 at 17:06 +0000, Max Bowsher wrote:
> I'm working on this ... Robert's fix is a step in the right direction
> but there is quite a bit more to do.
>
> First, the current code explicitly only rebases a left-most path, which
> AFAICS is just completely wrong.
>
> Second, the parent selection logic needs to be rewritten.
>
> Intertwined with that, there's the conundrum of --always-rebase-merges -
> a behaviour I would make default and mandatory, since the opposite has
> the potential to discard desired changes made as part of conflict
> resolution.
Thanks for working on this.

To provide a bit of background; bzr-rebase was written for those
regularly rebasing on an upstream svn branch, it wasn't intended as a
tool do to large-scale history rewriting. This is the reason why it
basically only cares about the branch mainline and ignores merges from
upstream as they would reorder the mainline.

Cheers,

Jelmer

--
Jelmer Vernooij <email address hidden> - http://samba.org/~jelmer/
Jabber: <email address hidden>

[Max Bowsher (maxb)]

Jelmer: I don't understand how a merge can reorder the mainline?

Anyway, what's in my branch at the moment seems to fix this bug - there are test failures, but I suspect they're just in need of updating the expected output.

This is somewhat blocked on figuring out what to do with the skip_full_merged (not --always-rebase-merges) mode, which has gone from being broken in the sense of skipping too much to being broken in the sense of now skipping nothing at all. I've started a thread on the Bazaar ML entitled "bzr rebase: Change behaviour to be as if --always-rebase-merges specified, remove outright the current default mode".

[Russ Brown (pickscrape)]

I'd like to stick my oar in here and describe our use case for why getting this fixed would be really handy to us.

Our workflow (for code that makes up a website) consists of feature branches and two long-running branches. One of these long-running branches represents what is currently on the live platform while the other represents the staging platform.

Simplifying somewhat, we prepare releases by merging feature branches to the staging branch, and deploying and testing from there. At release time, the staging branch is merged to the live one, and the code is deployed live.

From time to time, we find during testing that one of the features we merged to staging isn't ready, and needs to be pulled from the release (to be added in later). So currently we laboriously uncommit from staging until we get to the revision before the merge in question, and then repeat the merges, excluding the one we want to pull.

What we would like to be able to do, is to create a second staging branch from the first at the revision before the one we want to exclude, and then just replay the merges from the original staging branch except the one we don't want. Then use the new staging branch in place of the original. This way, things like commit comments and suchlike don't need to be entered again. In most cases our feature branches don't conflict, so most of the time these would replay flawlessly. While this kinda works now, the merges are flattened and so history is lost.

Hope this helps in some way!

[Max Bowsher (maxb)]

I didn't realize there was already a test script attached to this bug when I wrote this. Mine is perhaps a little simpler.