[PATCH RESEND] revert: do not reverse hunks in interactive when REV is not parent (issue5096)

[Martin von Zweigbergk]

On Mon, Nov 14, 2016 at 2:52 PM, Martin von Zweigbergk
<martinvonz at google.com> wrote:
> On Mon, Nov 14, 2016 at 2:49 PM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
>>
>>
>> On 11/14/2016 10:36 PM, Martin von Zweigbergk via Mercurial-devel wrote:
>>>
>>> On Thu, Nov 10, 2016 at 3:20 PM, Martin von Zweigbergk
>>> <martinvonz at google.com> wrote:
>>>>
>>>> On Thu, Nov 10, 2016 at 10:11 AM, Sean Farley <sean at farley.io> wrote:
>>>>>
>>>>> Augie Fackler <raf at durin42.com> writes:
>>>>>
>>>>>> On Thu, Nov 10, 2016 at 9:19 AM, Pierre-Yves David
>>>>>> <pierre-yves.david at ens-lyon.org> wrote:
>>>>>>>
>>>>>>> On 11/07/2016 03:17 PM, Denis Laxalde wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> # HG changeset patch
>>>>>>>> # User Denis Laxalde <denis.laxalde at logilab.fr>
>>>>>>>> # Date 1475237490 -7200
>>>>>>>> #      Fri Sep 30 14:11:30 2016 +0200
>>>>>>>> # Node ID 4f7b7750403ce48e78d0f361236f65ac03584c3c
>>>>>>>> # Parent  d06c049695e6ad3219e7479c65ce98a2f123e878
>>>>>>>> revert: do not reverse hunks in interactive when REV is not parent
>>>>>>>> (issue5096)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> (note, we should make this a BC)
>>>>>>>
>>>>>>>>
>>>>>>>> And introduce a new "apply" operation verb for this case as suggested
>>>>>>>> in
>>>>>>>> issue5096. This replaces the no longer used "revert" operation.
>>>>>>>>
>>>>>>>> In interactive revert, when reverting to something else that the
>>>>>>>> parent
>>>>>>>> revision, display an "apply this change" message with a diff that is
>>>>>>>> not
>>>>>>>> reversed.
>>>>>>>>
>>>>>>>> The rationale is that `hg revert -i -r REV` will show hunks of the
>>>>>>>> diff
>>>>>>>> from
>>>>>>>> the working directory to REV and prompt the user to select them for
>>>>>>>> applying
>>>>>>>> (to working directory). This somehow contradicts dcc56e10c23b in
>>>>>>>> which it
>>>>>>>> was
>>>>>>>> decided to have the "direction" of prompted hunks reversed...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I still think this is not the right thing to
>>>>>>>
>>>>>>> To me, Having `hg diff`, `hg commit/amend/shelve -i` and `hg revert`
>>>>>>> showing
>>>>>>> the same hunk make sense and is really useful. In particular showing
>>>>>>> the
>>>>>>> change I'm about to revert makes a lot of sense when I revert to a
>>>>>>> parent¹
>>>>>>> or an ancestors, or anything in the background of the patch
>>>>>>> (precursors, or
>>>>>>> ancestors, or combination of these). I check the change I introduce
>>>>>>> since a
>>>>>>> given point and revert some. To me using a revert to fetch content
>>>>>>> from
>>>>>>> arbitrary unrelated changeset is a semantic drift of the command. Such
>>>>>>> semantic drift should not motivate change that alter the core goal of
>>>>>>> the
>>>>>>> commands.
>>>>
>>>>
>>>> I do agree with this point. How about introducing a "hg apply -r $rev"
>>>> that's a synonym for "hg revert -r $rev", except that it uses the
>>>> "apply" direction in interactive mode? I was positively surprised that
>>>> "hg apply" is not yet taken. Then we can consider even rejecting "hg
>>>> revert -ir $rev" unless $rev is ".".
>>>
>>>
>>> No other voices were raised, and JordiGH says "revert" sounds right to
>>> him, so patch queued. Thanks!
>>
>>
>> I'm not too sure bout what was the conclusion and what was queued.
>
> The conclusion was that most people want "hg revert -i -r $rev" to
> show the hunks to apply, which is what the patch at the start of this
> thread does. I said I "revert" doesn't sound natural to me for
> anything but reverting to the parent of working copy, but no one
> seemed to agree, so I queued what was proposed in the patch.

Pierre-Yves reached out and reminded me that he actually frequently
uses "hg revert -i -r .~1" to undo changes since that commit. Also, I
still personally feel that the people who want to undo changes since a
revision and the people who want to get changes from a revision are
thinking about it differently enough that they should be using
different commands. I think it would be good if we could find good
names for both of those operations. In my mind, "revert" is a good
word for the former (i.e. undoing), and I'm not sure what's a good
word for the latter (i.e. getting state from). It's still unclear to
me if others were turned off mostly by my proposed name ("apply") or
the idea of them being different operations.

I'll de-queue this patch for now, and we can talk (even) more about it :-/

>
>>
>> --
>> Pierre-Yves David