[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: merge conlict?

From: David Reitter
Subject: Re: merge conlict?
Date: Mon, 25 Jan 2010 17:10:36 -0500

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

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]