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

[Kevin Bullock]

On 12 Oct 2009, at 9:08 PM, Rob Landley wrote:

> In brief, if you don't look at the change _before_ you pull then  
> something is
> probably wrong, and if you did that then looking extensively at it  
> again after
> you merge seems less likely.

Pulling someone else's changes just means you have access to their  
(probably anonymous) branch. Why would there be anything wrong with  
that? If you're worried about pulling in a branch you won't use, you  
can always pull into a clean clone specifically for the purpose of  
examining and merging changes.

Conversely, if you *merge* without looking at the result (and/or  
running your test suite against it), that's a problem (probably). But  
even in the case you described, with a one-line change that you pretty  
much knew was safe, `hg ci -m merge` is pretty quick to type. :)

> Therefore, a "hg merge -c" to auto-commit if there was no mechanically
> detected problem with the merge seems to make sense for the same  
> general
> reason "pull -u" does, and grabbing unrelated changes from your  
> checked-out
> copy of the files seems darn non-orthogonal in what is basically a  
> pure
> repository operation.

There's two completely unrelated classes of possible problems with a  
merge here: one class that results from a diff not applying cleanly,  
and another that arises from a (cleanly-applied) patch horking up your  
program logic. The second class is not mechanically detectable by a  
diff tool. (It's probably mechanically detectable if you have really  
good test coverage, which amounts to a special-purpose tool to detect  
logic errors in your particular code.)

Therefore while I could see the use of an `hg merge -c`, I wouldn't  
see it as at all orthogonal to `pull -u`. A merge cannot be a repo- 
only operation*. (Neither is a `pull -u`, but that doesn't create  
history.)

* By repo-only operation, I mean one that manipulates *existing*  
changesets without modifying them. A merge creates a brand-new  
changeset in a not-necessarily-logically-consistent state.

> And in future I know to go back to "hg export" and "hg import"  
> rather than
> trying to pull.
> ...
> Most of the actual fiddling with branches I've done has been in git,  
> and I
> thought both that mercurial had an equivalent of "fast forward"  
> merging and
> that the technique could handle more cases than it did.


That's entirely up to you, and it's how I'd probably deal with  
occasional (non-core) contributors. But I'd encourage you not to use  
this experience as reason to swear off pulling-and-merging (in hg?)  
entirely. Many of the practices that git makes normative are much more  
dangerous than they'd have you believe (rebase, fast-forward merging,  
etc.). They're useful tools, but they probably shouldn't be the  
*default* ways of doing the things they do. Much easier to fat-finger  
your way into a corrupted history.

Pacem in terris / Mir / Shanti / Salaam / Heiwa
Kevin R. Bullock