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

[Pierre-Yves David]

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>>>
>     > wrote:
>     >
>     >
>     >
>     >     On 05/22/2015 05:37 PM, Laurent Charignon wrote:
>     >      > Hi,
>     >      >
>     >      > As you may have seen I worked on revert --interactive and
>     soon I will
>     >      > send some patches for hg uncommit --interactive.
>     >      >
>     >      > Both these commands raise a UI question that I have been
>     debating
>     >     with
>     >      > marmoute and sid0.
>     >      > The --interactive session let your choose what changes
>     are reverted.
>     >      > There is two main way to ask the question
>     >      > We wanted to have your thoughts on it, so I put a minimal
>     example
>     >     below
>     >      > with the two propositions.
>     >      > For the record, I want *proposition 1* and marmoute wants
>     >     *proposition 2*
>     >
>     >     The way I phrase the two solutions is as follow:
>     >
>     >     1) Show the action revert will perform (current implementation),
>     >     2) Show the change revert will cancel,
>     >
>     >
>     > When reverting to another revision (picking pieces from that other
>     > revision), I'm quite sure I want 1). And, therefore, I think I
>     want 1)
>     > in all cases for consistency.
>
>     Your sentence make me realized we can use revert in two ways.
>     a) reverting against an ancestor: (actually revert changes)
>     b) reverting against a "descendant": (fetching from it).
>
>
> There are revisions that are neither of those (siblings, uncles and such).

They fall intro the (b) case (this is what the quote around descendant 
were meant for, okay it was sneaky). I categorize the same way because 
your intend is "fetch change from REV".

(I'm also a bit curious about how often you need it a what you use it for)

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150526/d4aafe55/attachment.html>