Pure merges

[Stefan Monnier]

While reading the "Workflows, rebase, patch theory" thread, I was brough
again to think about the issue of "pure merges".

Just like in Arh, Bazaar's merge-commits can contain anything: ideally,
they only contain the actual merge plus just some conflict resolution,
but the user is free to actually include anything she wants in there,
including replacing the tree with something completely different.

So when doing cherrypicking and merging, Bazaar (just like Arch) cannot
just assume that the merge-commit is equal to the sum of the patches that
were merged.

So I suggest the following:

A merge-commit should be composed of not just 1 but 2 revisions: the
first is the pure merge and contains the tree in the state after the
"bzr merge" command (i.e. it may contain conflict markers and things
like that).  The second contains the changes the user made to resolve
the conflict (and/or any other change she felt like including in that
commit).


        Stefan