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

[Dennis Brakhane]

---------- Weitergeleitete Nachricht ----------
Von: "Rob Landley" <rob at landley.net>
Datum: 13. Okt 2009 12:13 vorm.
Betreff: Re: A tale of user-friendliness with "hg merge" and "hg rollback".
An: "Dennis Brakhane" <brakhane at googlemail.com>

On Monday 12 October 2009 16:42:44 Dennis Brakhane wrote: > On Mon, Oct 12,
2009 at 11:23 PM, Rob La...
Why my working store comes in as a magic third parent is an open question...

> But even if this > succeeds, Mercurial has know way of determing whether
the merge is > still cor...
It is possible for commits to be incompatible, yes.

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

> Not only will do_something_really_cool now probably segfault (possibly >
in a really cool way), e...
Pulling two incompatible fixes for the same bug tends to cause that sort of
problem, yes.

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

> This is why a merge happens in your working store (which should be > clean
before you merge).
My working store is almost never clean, therefore I should never do merges.
Check.

> Mercurial tries it's best to merge, but afterwards, you have to > confirm
that the merge still ma...
Or you could look at the changes before pulling them.  (If you do that, how
closely are you going to look at the changes a second time _after_ the
merge?
And if you didn't look at the changes before pulling them, how likely are
you
to bother afterwards?)

> If it does, you commit it. If it doesn't, you fix it, and then commit. >
Just because Subversion ...
It's not wise, it just matches real-world workflows.

> But I agree with you that the usability of merge could be improved, > it's
easier to shoot yourse...
hg merge -c

Commit if the merge detected no conflicts.  Sure it might introduce bugs.
 So
does patch "fuzz factor" support, yet people complain at you if you write a
patch implementation that doesn't support fuzz.  (Sigh.)

If your inspection of the changes before the pull doesn't look like the
merged
result will actually work... then why are you pulling it?  Ahem: then you
can
leave off the -c.

(Although I point out that in the case I was playing with it didn't even
_need_ a merge, it just needed to re-parent the comment as a patch against -
tip, which did in fact apply cleanly...)

I'll leave you guys to it.  I don't play to pull from other repositories
again
any time soon.  (Maybe I'll write a script to clone the repository and hg
export patches I can hg import to my repository, or some such...)

Rob -- Latency is more important than throughput. It's that simple. - Linus
Torvalds
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20091013/6f0bb0f0/attachment.htm