hg update: crossing branches vs. uncommitted changes.

[Peter Arrenbrecht]

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.

-parren