UI discussions for revert --interactive and uncommit --interactive

Martin von Zweigbergk martinvonz at google.com
Tue May 26 18:01:33 CDT 2015


Pierre-Yves and I spent some time talking about this on IRC. I see what I
was missing before. I agree with Pierre-Yves that it's most important to
get the common 'hg revert -i' case right to start with and we agree that it
should ask the user which hunks to discard, not which hunks to apply. It
would thus match the output of 'hg diff'.

The 'hg revert -i -r sibling' case is less important, but I care more about
this case than Pierre-Yves does. If we don't do anything special, it will
also ask the user which hunks to drop. I think this is backwards, even
though it's consistent with 'hg diff -r sibling'. Since it's an interactive
command, I think it's fine to make it less consistent and less surprising
by instead making it ask the user what hunks to apply. This can be done
later if someone cares enough. And since it's an interactive command, I
think it should be fine from a BC perspective to change it later.

Other thoughts?

On Tue, May 26, 2015 at 2:48 PM Martin von Zweigbergk <martinvonz at google.com>
wrote:

> On Tue, May 26, 2015 at 2:35 PM Pierre-Yves David <pyd at fb.com> wrote:
>
>>
>>
>> On 05/26/2015 02:02 PM, Martin von Zweigbergk wrote:
>>
>>
>>
>> On Tue, May 26, 2015 at 1:43 PM Pierre-Yves David <pyd at fb.com> wrote:
>>
>>>
>>>
>>> On 05/26/2015 01:25 PM, Martin von Zweigbergk wrote:
>>>
>>>  On Sun, May 24, 2015 at 3:08 PM Pierre-Yves David <
>>> pierre-yves.david at ens-lyon.org> wrote:
>>>
>>>>
>>>>
>>>> On 05/22/2015 06:01 PM, Martin von Zweigbergk wrote:
>>>> >
>>>> >
>>>> > On Fri, May 22, 2015 at 3:51 PM Pierre-Yves David
>>>> > <pierre-yves.david at ens-lyon.org <mailto:
>>>> pierre-yves.david at ens-lyon.org>>
>>>>
>>>        (I'm also a bit curious about how often you need it a what you
>>> use it for)
>>>
>>
>>  I think I usually use when I have a branch and I think of an
>> alternative approach, so I start from scratch, but I still want some pieces
>> from the old branch (perhaps test cases).
>>
>>  And will you often use `-i` for that?
>>
>
> Is -i already supported? If it is, I probably will use it for that.
>
>
>>
>>
>>
>>
>>>
>>>
>>>
>>>> In the ancestor case (a), `hg diff --rev (a)` would be consistent with
>>>> what solution (2) show during revert.
>>>> In the descendant case (b), `hg diff --rev (b)` would be consistent with
>>>> what solution (1) show during revert.
>>>>
>>>> I've to admit that I barely use the (b) case anymore. I used to need it
>>>> to rework stack of patch, but uncommit/fold/etc are fitting this need
>>>> for me now. My biggest usage of `hg revert` is without a revision to
>>>> clean up silly change (debug print) or against an ancestors to try to
>>>> get something to work again.
>>>>
>>>> The consistency argument is interesting here, let's widen it. The most
>>>> important point to me is the consistency of the experience across all
>>>> commands. Mercurial is a VCS, vcs are mostly about handling "changes"
>>>> (hunks in this context). The vast majority of command present such
>>>> change in the same direction, from parent to child.
>>>>
>>>> commands          | direction
>>>> hg diff           | parent -> child
>>>> hg diff -r (a)    | parent -> child
>>>> hg diff -r (b)    | child  -> parent <- one exception
>>>>
>>>
>>>  With this history:
>>> x---a---c
>>>       \
>>>       @---b
>>>
>>>  Currently, it behaves this way (with clean working copy):
>>>  hg diff -r a | diff from a to @
>>>  hg diff r b  | diff from b to @
>>> hg diff -r c | diff from c to @
>>>
>>>  I think you're suggesting:
>>>  hg diff -r a | diff from a to @
>>> hg diff r b  | diff from @ to b
>>> hg diff -r c | diff from @ to c
>>>
>>>  I fear that a "hg diff -r a" followed by a "hg diff -r c" would
>>> surprise people, because the hunks corresponding to changes between @ and
>>> 'a' would be reversed between the two invocations.
>>>
>>>
>>>  I'm confused.  I'm not suggesting changing `hg diff` at all. I'm just
>>> pointing at how `hg diff` behave currently and how I think it is fine to
>>> have `hg revert` match this behavior.
>>>
>>> Did you misunderstood me?
>>>
>>
>>  Maybe I did misunderstand you. I thought you were arguing that we 'hg
>> revert -i -r $rev' should show the diff *from* $rev is $rev is an ancestor
>> (and answering 'yes' *drops* the hunk), but it should show the diff *to*
>> $rev if it is not an ancestor (and answering 'yes' *applies* the hunk).
>> Correct?
>>
>>
>> I'm saying:
>>
>> - `hg revert -i --rev X` should show the same diff as `hg diff --rev X`
>> - `hg diff --rev X ` should stay unchanged
>>
>> This mean "reverse change" when C is a "descendant" From there, it can be
>> either:
>>
>> - Drop the hunk [Yn]
>> - Keep this hunk [yN]
>>
>
> Okay, I see what you're saying (the same thing as you said from the
> beginning, but I somehow thought you changed your mind a bit). In that
> case, I maintain that I would be surprised if "hg revert --rev X" where X
> is a sibling were to show me a diff from X to @. I would expect a diff from
> @ to X.
>
> I understand if the word 'revert' makes it sound like you're undoing
> something, but when X is a sibling, that's not the case (at least for my
> uses).
>
>
>> (also keep curse UI in mind)
>>
>> This mean the "descendant" case show a strange hunk, but so does `hg
>> diff` in this case.
>>
>>
>> --
>> Pierre-Yves David
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150526/85afd9a5/attachment.html>


More information about the Mercurial-devel mailing list