Re: merge conlict?

[Óscar Fuentes]

David Reitter <address@hidden> writes:

> 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),

The discussion about uninformative commits merged into trunk finished
long time ago. This is about applying to private branches the quality
standards used for public branches like `trunk' (do not break the build,
remove debug code, etc)

> 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.

I don't think that appending the local branch's commits to the public
branch is a good idea. You end with a linear history, but with lots of
details and warts that may be better hidden from the default log view.

Linus wrote somewhere about this, explaining that `rebase' is great for
small projects and private branches, but it is not a great idea to
create linear histories on public branches of large projects with
several developers.

> 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.

Precisely, what I advocate is an style that allows unclean commits to
local branches. Not precisely garbage, but points that could do any kind
of breakage or go against coding standards.

> Does bzr generally make the merged history available?

Yes: bzr log -n0

[snip]