Pure merges

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vincent Ladeuil wrote:
|>>>>> "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".

bzr remerge file_i_pounded_on

works better for me.

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

Again, bzr remerge is your friend.

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

I don't worry about committing test-clean until it merges to trunk. Given you
are asking for the same behavior (just done automatically) it seems like you
could just do "bzr commit" yourself. If you really want to be evil, you can do
alias bzr-merge="bzr merge; bzr resolve --all; bzr commit -m 'merge'"

And then you get exactly what you are asking for. Or just

~  bzr-merge='bzr merge; bzr commit -m "merge"'

Then the commit fails if there are conflicts, but otherwise succeeds.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgiFWcACgkQJdeBCYSNAAPL9gCgm7I/1n0W08DJlNNH1pb66sEH
tdsAoNVb3iW1hemYWdJe0EhYSE8QqLJa
=BTYu
-----END PGP SIGNATURE-----