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

[Rob Landley]

On Tuesday 13 October 2009 07:23:08 Paul Moore wrote:
> 2009/10/13 Rob Landley <rob at landley.net>:
> > Explicitly trying to be dumb is one thing.  This was a one-line commit to
> > a file that didn't have any changes within a dozen lines of that commit,
> > a case where exporting a diff and applying it as a patch would have
> > worked just fine. What surprised me was mercurial being dumber than
> > diff/patch.
>
> How is Mercurial dumber? Diff/patch doesn't commit either.

I meant that the diff/patch thing applied cleanly, produced the exact same 
resulting tree, and only required one step (commit) instead of five (remote 
commit, pull, upgrade, merge, second commit) to save it to the repository.

In each case, if you add one commit to the repository, diff/patch is finished 
and pull -u is not.  In the diff/patch case, uncommitted changes to local files 
that weren't involved in the transaction are irrelevant, in the 
pull/update/merge/commit case any unrelated changes you have to the project's 
documentation directory and such become entangled.

Merge is not orthogonal.  Even though the commit was already in the 
repository, the process tried to involve _all_ the working files.  There was no 
way to say "I know this will merge cleanly, just do it, and my working copies 
should not be involved in this process" without backing out local changes to 
all my working files to humor the way merge is implemented.

> Diff/patch don't notice that you have other uncommitted changes in
> your working directory, but it's a pretty long stretch to claim that
> noticing this fact makes Mercurial "dumber".

It's not a question of "notice".  It didn't _care_, because it didn't need to.

> Just because Mercurial doesn't do what you think it should, doesn't
> make it "dumb".

I didn't introduce the phrase "trying to be dumb", the message I was replying 
to did.  Entirely possible I misinterpreted what he meant by it, but he 
_seemed_ to be offering it as a virtue.

> And criticising the software on such a basis doesn't
> make people inclined to help you.

Thanks for the tip.

I wasn't trying to ask for help with merge commits having a convoluted user 
interface, I was asking for help with the entire repository vanishing and 
included what I thought was the reproduction sequence.  The problem turned out 
to be an artifact of a clone I'd forgotten I'd done interacting badly with 
rollback, and not a pull/merge issue at all, so that was my mistake and I 
believe that issue to be resolved.

Since then, I've only replied to people who email me directly and haven't even 
looked at the list yet.  Matt pointed me at the redbook (which didn't exist 
when I started using Mercurial), and I'm reading it.

I'm also avoiding "pull" in future.  The fact is, I'd previously only been 
using hg import/export, and had come to expect its behavior (not requiring 
additional steps, letting me skip ancestor commits and automatically re-
parenting the commits when I --force the issue).  It turns out pull has all 
sorts of additional restrictions and requirements for no readily apparent 
reason.  How these extra steps are necessary one context but not in the other 
is something I don't understand, and have mostly stopped trying to.  I thought 
the mechanisms could at least be --forced to offer equivalent behavior when 
dealing with the same batch of commits: they can not.  (This is actually two 
separate issues: the inability of pull to reparent simple commits the way hg 
import does, and merge entangling your local files with what seemed like a 
purely repository operation.) 

I.E. I thought pull could do what import/export could do.  It can't.  Feel 
free to take that as criticism of "pull" and get defensive about it, but I'm 
happy switching back to import/export and moving on.  I only brought it up due 
to the repository vanishing thing, which was behavior I did not expect and 
which I (wrongly) thought might be of interest to others.

> Paul.

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