hg update: crossing branches vs. uncommitted changes.

[Peter Arrenbrecht]

On Tue, Mar 17, 2009 at 10:04 AM, Christian Boos <cboos at neuf.fr> wrote:
> 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?

I thought `hg update` has a bit more smarts than a simple diff/patch.
Which is why I'd like to use it.
-parren