bazaar-ng talk on darcs mailinglist.
rooneg at electricjellyfish.net
Wed Mar 23 16:01:02 GMT 2005
Martin Pool wrote:
> The basic question is: should you need to commit after a merge to put
> the changes into the destination branch? There are arguments either
> way. Perhaps the strongest argument in favour is that the user should
> always have a chance to review or test changes before they're committed;
> on the other hand it is simpler to work with only a single command. A
> compromise position is to handle 'trivial' merges differently, where
> trivial means either we can prove they're trivial because of the history
> graph, or because there are no conflicts and the build/test passes.
> The main feature I'd like to take from Arch in handling merges is the
> ability to make roll-up commits, representing the merger of several
> changes onto a branch. On the other hand Arch doesn't let you merge
> changes without creating new commits, which seems unfortunate.
> As of 22:24 tonight, I am leaning towards something a bit more like the
> monotone model, and somewhat like the darcs model, where the revision
> comes in and unless it's a trivial merge there is a separate commit to
> put it on the destination branch.
I'm not sure I buy the whole "detecting a trivial merge" part of the
equation... Just because the revision history of the file in question
implies there can't be a conflict there doesn't mean there isn't a
semantic conflict with other changes in the codebase, and relying on the
user to have iron-clad build/test automation that catches such problems
seems kind of naive. In many cases it just seems like it will result in
merges that while technically non-conflicting will result in broken
functionality. Requiring a separate commit seems like the only safe
course of action IMO.
More information about the bazaar