Re: [PATCHv2] Teach --no-ff option to 'rebase -i'.

Hi Marc,

Marc Branchaud wrote:

[...]

I think this rationale should go in the commit message, for the sake of future readers studying the code you’ve changed.

But let me make sure I understand it.

If I am understanding properly, your idea is that this would be used on a branch after “unmerging” it from master:

    B --- C --- D [topic]
  /              \
 A ---  ...   --- M ... --- U [master]

Here M is a merge commit and U a commit reverting the change from M^ to M.

As howto/revert-a-faulty-merge explains, this is an accident waiting to happen: if you merge master into topic, then it will pull in the revert along with the rest of the changes. Similarly, if you merge topic into master, it will be a no-op (“already up to date”).

Your solution, to rewrite the branch, should address both of these problems. The new history looks like this:

    B' --- C' --- D' [topic]
  /
 |  B --- C --- D
 |/              \
 A ---   ...  --- M ... --- U [master]

What happens now if you merge topic into master (or master into topic)?

Git will try to reconcile the changes from the two branches since when they diverged. master gained the changes from the old topic branch and then reverted them since it diverged from topic; since merge algorithm is a simple three-way merge, all that history is ignored and Git will just combine any new changes from master with the changes from topic. Success.

Side note:

After this maneuver, I would want to merge ‘master’ into ‘topic’ as soon as possible. Why? Because there is still a failure mode possible after this: if you merge any commits from the old topic into the new one before then, you’re back in trouble. This could happen if some topic2 that topic ends up needing is based on a point in master after M and before U.

After merging master into topic, the _meaning_ of the history is much clearer: by making U an ancestor, we are saying that as far as this branch is concerned, the state at the tip of the topic branch is to be preferred over the reverted state.

This suggests an alternative method to achieve your goal:

 git checkout master
 git revert -m 1 M;	# (1)
 git checkout topic
 git merge master^;	# (2)
 git merge -s ours master;	# (3)

1. Add a commit U removing the changes introduced by topic from master.

2. Merge all changes from master before the revert into topic.

3. Declare the changes from topic to supersede the master branch.
   This way, if topic is ever merged back to master, the changes will be
   reintroduced again.

Resulting history:

    B --- C --- D --- ... --- T^ --- T [topic]
  /              \            /     /
 A ---   ...  --- M ... --- U^ --- U [master]

You can avoid the perhaps pointless commit T^ by using --no-commit in the command (2). If not all changes from M..master are suitable for merging into topic, you can use the same trick on a temporary side branch:

 git checkout -b revert-topic M
 git revert -m 1 M
 git checkout topic
 git merge --no-commit revert-topic^
 git merge -s ours revert-topic
 git checkout master
 git merge revert-topic

If not all changes from topic..M are suitable for merging into topic, then things are harder. I’d suggest making a special unrevert-topic branch as above to keep in the wings until its time.

Hope this helps clarify things.

Your patch itself might still be a good idea. I think plain ‘git rebase’ already has something like it, in the form of the --force-rebase option. I have used it before, though I don’t remember why.

Thanks for the food for thought, Jonathan