bzr merge should do a pull instead of merge if this is possible
Bug #69487 reported by
Nicholas Allen
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
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.
To post a comment you must log in.
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 problems( )
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_
| /
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.