[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