Using merge --pull

[Eli Zaretskii]

> Date: Sat, 16 Jan 2010 09:39:57 -0500
> From: Gordon Tyler <gordon at doxxx.net>
> 
> > And a related question: if "bzr merge" does not find any conflicts,
> > what is the reason for it not to commit the merges automatically right
> > away?
> 
> Just because it merged without conflicts doesn't mean that the result is
> semantically correct. The two-step merge -> commit should actually be
> merge -> test -> fix if necessary -> commit.

Thanks, that makes sense.  But similarly, I could test _after_
committing, fix whatever needs fixing, then commit the changes, right?
Assuming the merge is in the branch where I'm developing a feature,
and the source is the parent branch to which I will eventually submit
my changes, there really is no difference between these two, is there?

Could it be that the current operation is biased towards a use-case of
accepting merges from a less trusted branch to a more trusted one (or
to a trunk), where the person who merges may wish to reject the
changes if they don't pass the tests?  If so, won't "bzr uncommit" fix
that use-case?  And the person who does this is anyway likely to be
more experienced with Bazaar than the one in the previous use-case, so
the possible complication of uncommitting is not a serious one.  By
contrast, less experienced users who started a branch just to try
things out would be served better by automatically committing from the
parent upon a merge.