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

[Kevin Bullock]

On Nov 8, 2010, at 10:37 AM, Haszlakiewicz, Eric wrote:

>> -----Original Message-----
>> From: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com]
>> On 5 Nov 2010, at 1:47 PM, Robert Figura wrote:
>> 
>> Well, it wouldn't happen on a normal `hg up`, as that invokes the usual
>> merge machinery. It would only write *.orig files on an `hg up -C`, which
>> is only needed when crossing branches. So I wouldn't see it happening
>> terribly often-unless you're in the habit of leaving uncommitted changes
>> around while switching back & forth between branches in the same clone. (!)
> 
> 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.

> 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` ?

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?

Or, if you know ahead of time that you'll likely be working on multiple branches at once, why not make a local clone for each to begin with?

On the other hand, having a more reliable/easy-to-use built-in shelve mechanism is high on my hg wishlist.

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

> Well, I'm not ready to check things in, so now I'm stuck unless I save my changes to a patch file (which from my understanding is what extensions like record or shelve or mq do); not the most user friendly interface, especially when I'm used to using other source control tools that handle this automatically. :(
> 
> eric