rollback deprecation

[Angel Ezquerra]

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.

I think that until we get a proper uncommit or purge command into
mercurial core --amend will not be a very good solution to this
problem.

>> The same way we've always recommended: clone up to the parent of the
>> bad revision (and any other heads), then throw away the old clone.
>
> That advice may be technically true, I think it is only half the truth.
>
> Even for a very small project like Mercurial where 'make local' takes
> seconds, you typically need more than what you describe here: you need
> to copy your .hg/hgrc file (mine contains useful paths), copy any patch
> queues (plural) you have around and maybe copy .hg/strip-backsups. Did I
> forget to copy something related to evolve -- I'm not 100% sure.
>
> So it is not just a matter of
>
>   cd ..
>   hg clone -r '.^' foo foo-stripped
>   rm -r foo
>   mv foo-stripped foo
>
> (four commands!) to remove a commit.
>
> You probably know this already, but things become more complex when the
> working copy contain costly build artifacts. Please don't ignore that by
> telling people to "just clone and throw away the old repo".

My thoughts exactly. Although as Matt told me it is nice that
mercurial's approach to deprecating commands does not stop me from
keeping using rollback until a better obsolete-based alternative gets
into mercurial core.

Cheers,

Angel