Re: merge conlict?

[David Reitter]

On Jan 25, 2010, at 4:24 PM, Óscar Fuentes wrote:
> It is very likely that if strict commit requirements are imposed on
> private branches, people will refrain from doing local commits at
> all. If you have to think hard and review and test before doing a  
> local
> commit, you will delay it as much as possible, or completely avoid
> it.

You're both right.  One of the contributors who is working with me on  
Aquamacs and I have been discussing this last night.  Even though  
we're using Git, it should still be relevant.

To avoid uninformative merge commits on the trunk (master), I  
suggested to use "git rebase" in lieu of "git merge" whenever a  
private (unpublished) branch is merged into the trunk.  Otherwise, the  
merge commit comment refers to branches that are not visible as named  
branches or tags to others, even though their content and history is  
(and I guess it'll be the same in bzr).  Rebasing in that case is  
easy, and cleaner.  (It's got nothing to do with rebase "surgery" on  
published branches, i.e., undoing history).  The non-linear commit  
history that you're discussing is another reason that I wasn't even  
thinking about.

http://wiki.bazaar.canonical.com/Rebase
Would this be useful?

If the commits on the private branch aren't clean, then rebasing  
clearly won't help.  Doing a merge with a reasonable commit message  
(listing all changes, but not any possible "back and forth",  
"trial&error" changes, sounds much better.

Does bzr generally make the merged history available?  Or would the  
branch need to be pushed?
(Git pushes all reachable revisions, I think, which is why I'm  
assuming bzr does the same, but maybe I'm wrong.)