Linear backout (was Re: How I deleted my new files with good help from Mercurial)

[Nigel Rowe]

On Wed, 30 Jun 2010 21:43:24 +0200, 
Daniel Carrera <dcarrera at gmail.com> wrote in a message 
with the id 
<AANLkTikT7ya69FAoTY1B20YwhRCNMfWy-3QYLDWcsBQL at mail.gmail.com>:
>
> On Wed, Jun 30, 2010 at 9:28 PM, Greg Ward <greg-hg at gerg.ca> wrote:
> > Agreed.  I have not looked at how backout is implemented, but I bet
> > it's really close to my "backout without merge" trick.  If so, it
> > should be easy to add an option that makes it update to the branch
> > tip before committing the backout.
> >
> > I dislike both "--detach" and "--rebase" for that option because,
> > well, there's no detaching or rebasing anywhere in sight.  Ideas:
>
> I don't see any problem with a "cancel" command, but I sympathize
> with not wanting to add more commands. But in any case, I also
> dislike --detach and --rebase for exactly the same reasons you
> stated.
>
> >  hg backout --linear    # update before commit keeps history linear
> >  hg backout --tip         # commit the backout at branch tip
> >  hg backout --right-here  # commit the backout right here
> >  hg backout --target REV      # commit on top of REV
>
> Among these, I would vote for --linear. Alternatively, there could be
> a config option:
>
> [ui]
> backout.linear = True
>
> It would also be nice if "backout" could accept a range of revisions
> in both linear and non-linear mode.
>
> Daniel.


Greetings,
  how about

$ hg inverse -rREV

since that's what is being done, you are creating an inversion of a REV 
and applying it 'here'.  (Or maybe hg invert -rREV)

Backout never seemed right to me, because you're not removing a rev, 
you're adding one.

Cancel doesn't seem quite right either since your aren't cancelling the 
rev itself (think going up the page and crossing it out).

Undo should be reserved for a general purpose undo.

My 3c worth (adjusted for exchange rate).

Nigel
Nigel

-- 
    Nigel Rowe
    rho \N{COMMERCIAL AT} fisheggs \N{FULL STOP} name