A tale of user-friendliness with "hg merge" and "hg rollback".

[Mike Meyer]

On Tue, 13 Oct 2009 00:20:07 +0200
Dennis Brakhane <brakhane at googlemail.com> wrote:
> > vod barfoo(void* baz) { > do_something_with(baz); > free(baz); //Friend:
> fix memory leak > do_...
> How does "fixing that in the next commit" differ from having the merge do
> something other than merge?

Because the build (from the repo) isn't broken while you're fixing it
if you fix it in your working copy first. And how does having merge
commit to the repo *not* involve it doing something other than merge -
like a commit?

> Expecting people to inspect the merge result by hand every time seems
> unrealistic somehow, especially when you can just make a
> "mergecommitdammit.sh" wrapper instead...

Expecting people to actually load the gun by hand every time seems
unrealistic somehow, especially when you can just make a
"shooteveryoneinthefoot.sh" wrapper instead...

With a best practices workflow, you don't "inspect the merge results
by hand", you run the test suite against the working copy created by
the merge, then commit it. Just like you run the test suite against
*any* changes you make before you commit them. At least if you're
committing to a branch that people expect to get working code from.

Personally, I've used svn long enough I always inspect merge results,
no matter what SCM I'm using.  Typically by asking for a diff between
what's in my working copy and what's in the repo after doing the
merge.

> My working store is almost never clean

This would suggest you're not taking optimal advantage of your
tools. In particular, that you leave incomplete changes in your
working copy to start on the next one. If that's not the case, my
apologies. Handling such properly means creating separate working
copies for each change, which isn't something that core mercurial
handles very well. In git, you'd use their lightweight branch
mechanism. Mercurial's branches are a bit much for that, so there's
lots of extensions around to help out. mq is really popular. I use the
tasks extension, and I vaguely recall an "attic" or "shelve" extension
that lets you save changes to the working copy and pull them back
later.

	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org