bzr merge should do a pull instead of merge if this is possible

[Nicholas Allen]

When merging from a branch and the branches have not diverged but the branch we are merging from has changes that are not in the target branch then bzr should do a pull instead of a merge.

[John A Meinel (jameinel)]

I think this is still a point of debate in the community. I have a specific example where having a merge at that point is actually quite useful.

A merge point can represent a combining of a bunch of work on a feature, and gives a good point to indicate when that feature was merged into another branch. As an example:

v- public tree
    v- Feature branch
        v- Commit message
A # Release 0.1
| \
| B # Add function foobar to create feature foo
| |
| C # Crush the bugs and hear the lamentations of the evil
| |
| D # Ooops, missed one
| |
| E # use foobar in solve_all_problems()
| /
F # [merge] foobar solves all problems

A fairly involved feature branch can be summarized in the commit F. So that looking at the A, F history, you can see the release, and then that feature "foobar" was added.

If you used fast-forward, you wouldn't get the opportunity to create the summary information, and if you were answering the question:

  When was "foobar" added to the public branch

You would probably search through the logs and see the log for B, when it was created, but it may not be clear that it wasn't ready until E to actually be used.

[Martin Pool (mbp)]

Let's talk more about this on the main list. As John says, specifically recording the merge can sometimes be useful. Perhaps it should be optional.

[John A Meinel (jameinel)]

You can now use 'bzr merge --pull' if you want this behavior.

You can even set it as an alias in ~/.bazaar/bazaar.conf with:
[ALIASES]
merge = merge --pull

If you always want that behavior.