"hg up -C" is also evil - ;-)

Haszlakiewicz, Eric EHASZLA at transunion.com
Mon Nov 8 11:31:15 CST 2010


>-----Original Message-----
>From: Kevin Bullock [mailto:kbullock+mercurial at ringworld.org]
>On Nov 8, 2010, at 10:37 AM, Haszlakiewicz, Eric wrote:
>> The problem is that hg up does *not* invoke the usual merge machinery if
>you go from one branch to another.
>
>That was precisely my point, which is why it might be sensible to write
>*.orig on an update crossing branches. The required `-C` flag is a clue
>that it's doing something potentially destructive to your working dir.

I don't understand why you want .orig files.  I want to KEEP any changes in the files I have changed.  I don't want to move them to .orig files.  The only time I see it being useful to have .orig files is if there's a conflict during the update.


>> It's pretty easy to be switching between branches if you happen to have
>more than one person working on the code (or even if you don't always work
>on the same machine).  e.g.:
>> 1) modify and check in some file.
>> 2) modify another file (or ten), but then decide to check if anyone else
>has been working on the same stuff.
>> 3) do a pull.
>> 4) Oh gee, there are a bunch of changes, let's update and see what those
>are.  oops, "hg up" doesn't work because it's switching branches.  Neither
>does "hg merge" b/c I have local changes.
>
>Why `hg up` and not just `hg log -pr.:tip` ? Or, if you just want to see
>the aggregate changes, `hg diff -r.:tip` ?

Because it's often easier to see what's going on when you're working with a completely updated directory tree.  Also, because update would actually merge things and either eliminate any duplicate changes or issue a conflict.

>Or, go one step further and say you want to play around with (or run tests
>on, etc.) the other dev's changes. Why not make a local clone as a sandbox
>and play around in that, then decide whether to commit or revert your
>working dir?

In some cases, sure, that's useful, but many times I don't want to worry about another clone to clean up later (and check for changes, and possibly need to merge changes in, etc...).

eric


More information about the Mercurial mailing list