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

Pierre-Yves David pyd at fb.com
Tue May 26 16:35:17 CDT 2015



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 
> <mailto: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
>>     <mailto: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>
>>         <mailto: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?

>
>
>>
>>         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]

(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/53a1e215/attachment.html>


More information about the Mercurial-devel mailing list