bazaar-ng talk on darcs mailinglist.

[Garrett Rooney]

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.

-garrett