[PATCH] update: add a hint when aborting for uncommitted changes

[Martin von Zweigbergk]

On Wed, Apr 5, 2017 at 1:39 PM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> On 04/05/2017 05:17 PM, Martin von Zweigbergk wrote:
>>
>>
>>
>> On Apr 5, 2017 04:01, "Pierre-Yves David"
>> <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
>> wrote:
>>
>>
>>
>>     On 04/05/2017 07:29 AM, Martin von Zweigbergk wrote:
>>
>>         On Tue, Apr 4, 2017 at 9:40 AM, Pierre-Yves David
>>         <pierre-yves.david at ens-lyon.org
>>         <mailto:pierre-yves.david at ens-lyon.org>> wrote:
>>
>>             # HG changeset patch
>>             # User Pierre-Yves David <pierre-yves.david at ens-lyon.org
>>             <mailto:pierre-yves.david at ens-lyon.org>>
>>
>>             # Date 1491225382 -7200
>>             #      Mon Apr 03 15:16:22 2017 +0200
>>             # Node ID 32116e1ad0d93b48d344f317899b974628310850
>>             # Parent  2632df096fc0ac7582382b1f94ea4b9ad0bce8f2
>>             # EXP-Topic update.mergehint
>>             # Available At
>>             https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
>>             <https://www.mercurial-scm.org/repo/users/marmoute/mercurial/>
>>             #              hg pull
>>             https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
>>             <https://www.mercurial-scm.org/repo/users/marmoute/mercurial/>
>>             -r 32116e1ad0d9
>>             update: add a hint when aborting for uncommitted changes
>>
>>             Plain abort is a bit frustrating for the user. We now point
>>             at the '--merge' option
>>             in the hint. This is similar to what evolve 'next' and
>>             'prev' do. Not that
>>             evolution use a more direct hint "(do you want --merge)",
>>             but it might be a bit
>>             too error prone for new user.
>>
>>             diff --git a/mercurial/hg.py b/mercurial/hg.py
>>             --- a/mercurial/hg.py
>>             +++ b/mercurial/hg.py
>>             @@ -761,7 +761,8 @@ def updatetotally(ui, repo, checkout, br
>>                          ret = _clean(repo, checkout)
>>                      else:
>>                          if updatecheck == 'abort':
>>             -                cmdutil.bailifchanged(repo, merge=False)
>>             +                hint = _('to merge these changes with
>>             destination, use --merge')
>>
>>
>>         The existing messages say "commit or update --clean to discard
>>         changes". I sent a patch to also suggest --merge in the
>>         updatecheck=linear case (i.e. the legacy and default case), but we
>>         ended up dropping that because it's hard to recover from the merge
>>         state.
>>
>>
>>     Note that we could easily build a `hg update --abort` that makes it
>>     easy to recover.
>>
>>
>> I didn't realize we kept the uncommitted file content around somewhere
>> so it could be restored. But I know you can re-resolve a file, so I
>> should have figured that out.
>>
>>
>>
>>         I don't see a reason that we should recommend something
>>         different when updatecheck=abort. Using a hint of "commit or
>> update
>>         --clean to discard changes" seems completely uncontroversial.
>> Should
>>         we do that instead? Or should we start recommending --merge (for
>>         both
>>         these cases) despite the risk? I'm not sure.
>>
>>
>>     My usecase for "abort" is "I do not want to move away with
>>     uncommitted change without realizing it". They are a good chance I
>>     actually wanted to commit or amend the change locally. I'm using the
>>     "uncommited change" in prev/next the same way. However they also are
>>     many case where I actually want the merge to happens (and I'll use
>>     --merge).
>>     In such case the hint with --merge in it provides me with a clear
>>     visual hint that the abort is not a bit deal and that they are an
>>     easy way forward.
>>
>>     The hard abort with no hint looks like something serious with no
>>     easy solution is happening to my repository.
>>
>>     In my current opinion is that we should:
>>     1) get `hg abort --abort`
>>
>>
>> Yes, please! (You obviously meant "hg update --abort" here too.)
>
>
> So, the usual question comes up again. Who should be doing it o:-) Since you
> have spend quite some time in this area do you want to do it? This is
> probably about ½ a day of work.

Maybe. I won't have time before my vacation, which starts in two days
and lasts for two weeks. I may look into it after. It probably won't
be right after, though.

>
> Cheers,
>
> --
> Pierre-Yves David