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

[Rob Landley]

On Monday 12 October 2009 15:36:06 Tim Bell wrote:
> Rob Landley wrote:
> > My friend mark did a one-line commit in his repository, and it seemed
> > safe to pull it.  It was _one_line_.  This made his commit the "tip" of
> > my repository, obscuring the last half-dozen commits I'd done.
>
> I _always_ do the pull and subsequent merge in a disposable repository
> created brand-new for that purpose.

It was a one line fix.  And I knew I had the copy on the website, I just 
thought the pull had _worked_.  I didn't immediately notice it needed to be 
merged (it's a one line fix that trivially could have been handled as a patch), 
and then when I _did_ the merge I didn't immediately notice that the merge 
itself had been a NOP.

> 1) Clone from your project master to some scratch area
> 2) Pull into 1) from your friend Mark's repository
> 3) Merge
> 4) If you like what you have, push it to your project master
> 5) If not, burn the disposable repository and start over

If it's my project, do I do the merge or does the guy I'm pulling from do a 
merge?  (I'm pulling, not pushing.)  I thought pull -u would merge as 
necessary, but apparently not.  (When I did hg import/export it didn't need a 
merge, but pull apparently always does even for one line things?  Why?)

I feel there's something I should read on this, but I dunno what it is.  
(Navigating a wiki snapshot du jour is potluck...)  I've also happily gone 
three years using mercurial without having to deal with any of this, and am 
wondering if it's really worth it.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds