hg update: crossing branches vs. uncommitted changes.

[Christian Boos]

Peter Arrenbrecht wrote:
> On Sun, Mar 15, 2009 at 11:01 PM, Gilles Moris <gilles.moris at free.fr> wrote:
>   
>> On Sun March 15 2009 19:02:27 Douglas Philips wrote:
>>     
>>> Is there a philosophical reason in the Mercurial gestalt for using the
>>> -C option for both "wipe out uncommitted changes" and "yes, I really
>>> did mean to cross branches"?
>>>
>>>       
>> BTW, there is no need of -C to cross to another named branch.
>> I have never understood the segregation between update to named branches
>> and update to local heads. Why the latter should be prevented, provided
>> a rev is explicitly given to the update command ? I do not find it very
>> consistent. In a way, local heads are usually "closer" than developments in
>> named branches.
>>
>> In my mind, crossing branches should only be prevented when no rev is given
>> to the update command. Any reason why this would not be the way to go ?
>>     
>
> Seconded.
>
> Also, what do people think of having a new option, --carry-over maybe,
> to tell update to carry pending changes over across heads (named or
> not)? Conceptually, it could be done by first updating to the common
> ancestor, then to the target. But probably better on a
> per-file-ancestor basis. I have read somewhere that backwards update
> with pending changes is somewhat shaky, which is why I propose an
> explicit flag for this - so people know what they are doing.
>
> Sometimes I even have pending changes affecting files that haven't
> changed at all between the two heads. For these the -C requirement is
> especially galling.
>
> I would be willing to attempt a patch if it sounds acceptable. This
> scenario occurs not infrequently when working pbranch-style.
>   

Note that we have the same problem with MQ and pending changes when 
doing a qpush/qpop/qgoto, where currently the only choice is to abort or 
force the operation which sometimes throws away the local changes. 
There, a similar --carry-over flag (or maybe --keep-changes/-k?) would 
be useful as well.

In the specific case of MQ, I think that keeping those local changes 
could be as simple as: first storing the local changes in a 
local_changes.diff file, doing a clean, do the actual operation, if 
successful, try to re-apply local_changes.diff and remove that temporary 
file.

Maybe this simple approach would work for switching between named 
branches as well?

-- Christian