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

[Kevin Bullock]

On Nov 8, 2010, at 11:31 AM, Haszlakiewicz, Eric wrote:

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

This is well beyond the original topic, though:

On 5 Nov 2010, at 7:12 AM, Marko Käning wrote:

> Yesterday I issued the command
> 
> 	$ hg up -C
> 
> actually believing that local changes would be moved into *.orig prior to 
> the clean update of my working copy.


I agree it'd be useful; I don't know if the merge machinery would even be _able_ to handle this in the general case, though. You'd have to do something like rebase the working dir (uncommitted!) changes onto the other branch, which is really multiple iterative merges, sometimes requiring manual fixup before the process can continue.

_I_ don't particularly want *.orig files, or care much whether the behavior changes from its current state.

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

Suit yourself, but that's the way that hg has provided to do it since the beginning, and it seems cleaner to me. You either make a throwaway clone, and then throw it away promptly, or you establish one local clone as your incoming queue.

If you really do want the workflow you mention w/in a single clone, though, MQ can handle it effectively.

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock