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

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed Apr 5 16:39:15 EDT 2017



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.

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list