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

Martin von Zweigbergk martinvonz at google.com
Tue May 26 16:48:09 CDT 2015


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/38392a8f/attachment-0001.html>


More information about the Mercurial-devel mailing list