Pure merges

[Vincent Ladeuil]

>>>>> "john" == John Arbash Meinel <john at arbash-meinel.com> writes:

    john> Stefan Monnier wrote:
    >> 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

    john> Why?

I always feel unsafe just after a merge because I lose the
ability to track *my* modifications with 'bzr diff'. I said 'my'
as in "this is how I resolved the conflicts, this what I added
to update my features against the changes coming from trunk,
these are the tests I have fixed or added".

So I'm often torn between committing as quickly as possible after
a merge and refrain from doing so to keep all my commits
'test-clean'.

    john> The content of that revision is then heavily dependent
    john> on what merge algorithm was used (--weave, --merge3
    john> --reprocess, --lca, etc). It doesn't give you a chance
    john> to "remerge" with different options, etc.

Very true.

I wouldn't mind creating a revision representing the merge with a
different behavior than usual revisions.

    john> What is the advantage of a "pure merge"?

Address the following scenario: "Geee, what an idiot I solved the
conflicts with a hammer !  Quick. bzr revert --no-backup, oops,
my modifications are gone".

<snip/>

    john> Certainly creating a commit with conflict markers seems
    john> a bit odd. Especially considering the "bisect through
    john> revisions" thread.

Yes :-/

So when I said different behavior above, I was thinking about
being able to get back to the working tree with the conflicts,
but when bisecting, being able to ignore it ;-)

    john> If you have a specific use case for it, I'm willing to
    john> entertain the thought. I just don't see what it
    john> actually adds.

Mostly dumping brain here... I miss the ability to separate the
result of the merge and my needed modifications ; being able to
express them via two commits instead of one is appealing. Or a
revision with two separate set of changes...

       Vincent