Pure merges

Talden talden at gmail.com
Wed May 7 22:25:46 BST 2008


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

I completely understand the intention, a merge revision and a resolve
revision created as part of the gesture of merging.

The merge revision should probably have some meta-data to indicate the
sources of lines (so that the merge-algorithnm is not effectively
encoded in the commit) and it should probably not contain the conflict
portions.  Those should remain uncommitted in the working-tree for the
resolve commit to apply. You can't commit anything conflicted in the
merge revision because not all conflicts can be represented in such a
way (consider the many forms of tree conflicts).

A merge revision should carry enough knowledge to guide annotate
correctly to the originating source of lines. IE line X is from rev A
merged in rev B, line Y was a merge resolve in rev B.

I have no idea how practical such a feature would be in general (I
simply haven't even thought about the data structures and use-cases
enough to confident that it covers the useful cases or even scales
well) but I expect that it's a very bad fit for the current Bazaar
approach (or any of the other merge-tracking models I've seen
personally).

--
Talden



More information about the bazaar mailing list