[PATCH 3 of 4 V3] update: also suggest --merge when non-linear update is aborted

[Matt Harbison]

On Tue, 21 Feb 2017 11:08:05 -0500, Augie Fackler <raf at durin42.com> wrote:

>
>> On Feb 20, 2017, at 05:38, Gábor STEFANIK <Gabor.STEFANIK at nng.com>  
>> wrote:
>>
>>> On Wed, Feb 15, 2017 at 12:56:41PM -0800, Martin von Zweigbergk via
>>> Mercurial-devel wrote:
>>>> # HG changeset patch
>>>> # User Martin von Zweigbergk <martinvonz at google.com> # Date
>>> 1487140898
>>>> 28800
>>>> #      Tue Feb 14 22:41:38 2017 -0800
>>>> # Node ID c6cd58d272aee6633fbad5eacdad742e2f9909cd
>>>> # Parent  542a99ede6c3ac7cb4afccd3703fcc30e3d4c90d
>>>> update: also suggest --merge when non-linear update is aborted
>>>
>>> This makes me a touch nervous, since the merge can leave the user in an
>>> state that's hard to recover from.
>>
>> Basically "hg resolve -au; hg resolve -at:local; hg update --merge  
>> -r$(head -c40 .hg/merge/state) -t:local"; but we need to expose a less  
>> hacky way of doing so.
>
> Not quite, because this isn't sure (I don't think) to get you back to  
> exactly the pre-update-command state, as some files might have been  
> merged behind your back?

Crazy thought- what if `hg update` were to do the equivalent under the  
hood:

$ hg ci --secret -m "backup for update"
$ src=$(hg log -r . -T "{rev}")
$ hg up $dest
$ hg rebase -r $src -d .

Rebase strips (or obsoletes), so the temp commit is gone.  If things go  
awry, `hg update --abort` is the equivalent of:

$ hg rebase --abort
$ hg up -C $src^
$ hg revert --all -r $src
$ hg strip --no-backup $src

This would restore files merged behind your back too.  Obviously it is  
only needed if a file changed in both branches between ancestor($src,  
$dest) -> $src and ancestor($src, $dest) -> $dest.  I've been pondering  
how to do that calculation with filesets, so at least there's an easy way  
to tell if there's a potential conflict beforehand.  Maybe a new  
'changed(rev)' fileset, that works like `hg status --change`?

>>
>> "hg update --abort"?
>
> I'd be a big fan of having an update --abort that just takes you back to  
> where you were before the conflicts. To date, nobody has been motivated  
> enough to do the work (I'd love to do it, but it's unlikely to be near  
> the top of my stack for months/years).
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel