rollback deprecation

[Martin Geisler]

Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:

> On 18 juil. 2013, at 16:01, Martin Geisler wrote:
>
>> Angel Ezquerra <angel.ezquerra at gmail.com> writes:
>> 
>>> On Thu, Jul 18, 2013 at 10:29 AM, Martin Geisler <martin at geisler.net> wrote:
>>>> Kevin Bullock <kbullock+mercurial at ringworld.org> writes:
>>>> 
>>>>> On 17 Jul 2013, at 9:07 AM, Antoine Pitrou wrote:
>>>>> 
>>>>>> Martin Geisler <martin <at> geisler.net> writes:
>>>>>> 
>>>>>>> 
>>>>>>> # HG changeset patch
>>>>>>> # User Martin Geisler <martin <at> geisler.net>
>>>>>>> # Date 1374050974 -7200
>>>>>>> #      Wed Jul 17 10:49:34 2013 +0200
>>>>>>> # Node ID 85d4ebb3d89e29657c4d7365174d9120ba88ad34
>>>>>>> # Parent  ea4342d0e6fea19c8c4b7651f36929cd682afae7
>>>>>>> rollback: add reference to "hg commit --amend"
>>>>>>> 
>>>>>>> Now that rollback is deprecated (yay!) users might need a pointer
>>>>>>> to the alternative for 99% of the cases where I used rollback.
>>>>>> 
>>>>>> Rollback is deprecated? What is the recommended way to undo a bogus
>>>>>> commit (especially a merge or graft)? AFAICT, "strip" isn't part of
>>>>>> the core command set.
>>>> 
>>>> You should be able to use 'hg commit --amend' in those case too. I
>>>> just tested it and I can amend both a merge commit and a graft
>>>> commit just fine with Mercurial 2.6.3.
>>>> 
>>>> So I believe the better answer to your question is to use --amend.
>>>> It is only if you need to really get rid of a commit (as opposed to
>>>> correcting it) that --amend falls short.
>>> 
>>> The problem with using --amend in this scenario is that it is not
>>> that easy to use it to uncommit a file. AFAIK the only way to do so
>>> is to revert that file to the its parent revision state and then use
>>> --amend.
>> 
>> Yes, that is unfortunately the way one has to use --amend. In other
>> words
>> 
>>  $ hg commit --amend -X foo
>> 
>> is not the same as
>> 
>>  $ hg rollback
>>  $ hg commit -X foo
>> 
>> since foo wont be excluded from the amended commit. I feel this is
>> surprising and unfortunate since I need to exclude entire files much
>> more frequently than I need to exclude changes to files when
>> amending. Also, from MQ works works like the rollback+commit
>> sequence.
>
> We already discussed that in the past.

I know we've discussed it before. I'm writing about it here since I'm
trying to figure out the best workflow with the --amend that we have
now. That's also why I'm contrasting with MQ and rollback: to figure out
how to best reimplement the old workflows in a safer way with --amend.

> There is three state we need to takes in account:
> 1) current working directory (wc)
> 2) working directory parent (.)
> 3) parent of working directory parent (.^)

I think you can add the working directory grandparent (.^^) to the list
of interesting revisions. If we imagine a recommit alias that does

  hg rollback; hg commit $@

then we can compare:

* I want to completely remove a.txt from the last commit but retain the
  changes in my working copy.

  With amend:

    $ hg revert -r '.^^' a.txt
    $ hg commit --amend
    $ mv a.txt.orig a.txt

  With recommit:

    $ hg commit --amend -X a.txt

* I want to fold all changes into the last commit without adding the
  changes in a.txt.

  With amend:

  $ hg commit --amend -X a.txt

  With recommit:

  $ hg diff a.txt > tmp  # stash
  $ hg recommit
  $ hg import --no-commit tmp

My impression (just an impression) is that I run into the first use case
much more than the second. When the second case happens, I've actually
never solved it with --amend, but always by reverting the change in my
editor. That way

  $ hg diff -r '.^^'

shows me what the commit will contain after commit --amend. Trying to
figure out what an amended commit will contain looks quite difficult
when -X is used: running

  $ hg diff -r '.^^' -X a.txt

will not give the correct result since it will exclude the changes in
a.txt made between '.^^' and '.^'.

In other words, I try hard to avoid ending up in the second case since I
don't know how to see the effect of 'hg commit --am' in that case!

> And it's hard to express that all at once in a single command. even
> harder when amend is an extra flag on the commit command. If the
> feature is so critical we can has it working separated from evolve.
>
> Haivng two commands commit//uncommit give a very clear interface in my
> opinion. The MQ way bites people all the time.

Thanks for the reminder, I should try to use 'hg uncommit' from evolve
more often.

-- 
Martin Geisler