[PATCH RFC] update: add an option to allow to merge local changes when crossing branches

[Pierre-Yves David]

On 14 mars 2013, at 10:42, Laurens Holst wrote:

> Op 13-03-13 19:09, Greg Ward schreef:
>> On 13 March 2013, Laurens Holst said:
>>> Op 12-03-13 19:02, Pierre-Yves David schreef:
>>>> On Fri, Feb 22, 2013 at 11:22:07AM +0100, Gilles Moris wrote:
>>>>> # HG changeset patch
>>>>> # User Gilles Moris <gilles.moris at free.fr>
>>>>> # Date 1361528509 -3600
>>>>> # Node ID 567106adefd309717d8f0538197dc7dde45d34f1
>>>>> # Parent  013fcd112f13f31a35ea6a40d8cd1c6923cdaf20
>>>>> update: add an option to allow to merge local changes when crossing branches
>>>> Let's sum up my opinion on that:
>>>> 
>>>> 1) We cannot have this behavior by default. preventing such update by default
>>>>    frequently save my changes.
>>>> 
>>>>    The same as mercurial prevent multiple operation in the middle of merge or a
>>>>    rebase.
>>>> 
>>>>    We need more of such safety
>>>> 
>>> Can you elaborate on how this abort saves your changes? Because it
>>> is not clear to me.
>> I think Pierre-Yves meant save as in "prevent unexpected/unwanted
>> merge" rather than "store a backup copy somewhere".
>> 
>> Here's the scenario: you have uncommitted changes that are valuable
>> but that you forgot about. You pull and new changesets land, so you
>> "hg update". Mercurial says "sorry buddy, no cross-branch updates for
>> you", which reminds you of your uncommitted changes. You can ignore
>> the pulled changesets and keep working, or commit and merge, or commit
>> and rebase.
>> 
>> It would perhaps have been more accurate for Pierre-Yves to say
>> 
>>   preventing such update by default frequently saves my bacon
>> 
>> but expecting perfect idiomatic English from everyone is unrealistic. ;-)
> 
> So, if there is an easy way to revert back to the state before the merge, there will be no need for an extra --merge / --stash flag. Right? From a UI perspective, that seems the way to go.

No, no, no!

I forget to finish what I'm doing before moving to something else:
- I forget to commit my merge after conflict resolution
- I forget to amend my change in the relevant commit before moving to something else.

And I'm usually reminded by mercurial telling me:
- uncommited merge
- refuse to update with uncommited changes
So I can avoid the error early.

There is some situation were is doesn't do it:
- earlier version of amend that did not detected merge in progress.
- when I amend instead of commit.

And even if it easy to revert (rollback is my friend here :-/) it would really prefer to have a small warning.

Summary: Warning about suspicious situation is great. we just need a way to override that. 

> Prompting the user to type his command again but with a special flag seems just as suboptimal as the update-to-ancestor thing. After typing the flag a couple of times, users will start typing it always just to avoid the abort. Then, the value of such a flag is reduced to less than zero, because users will have to type more and their forgotten changes are still not saved.

Disagree. User will use it when he knows he want to move changes around. If he does it all the time it is the kind of user that use `hg push --force` all the time and complains later about troubles.

> When I was attempting to implement a "--guard" flag to only update when there are no conflicts [1], I think the final outcome was also that rather than adding such a flag, there should be a way to easily back out of a merge while preserving changes in the working copy.

easing the restoration process is a good idea on a general basis

-- 
Pierre-Yves David