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

Mon Jun 1 23:01:35 UTC 2015

On Tue, May 26, 2015 at 11:01:33PM +0000, Martin von Zweigbergk wrote:
> 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'.
>

This seems like the obvious shape of the command to me, but I'd also
like to try it before feeling sure.

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

I honestly have no idea how revert -ir should work. It never even
occurred to me that it could work differently. I'm not sure that the
output should be different from diff -r, but it's probably worth
testing.

Not sure how I feel about allowing BC in an interactive command,
mostly because of the command server (which I think makes it easy-ish
to wrap stuff like this).

Sorry for thread necromancy, last week was too-busy for me.

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

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel