1121211 - qbackout without mq

Status: RESOLVED FIXED

(Developer Services :: Mercurial: qbackout, defect)

Description

[Steve Fink [:sfink] [:s:]]

I've wanted qbackout's functionality but using real commits.

See also bug 1117632.

Comment 1

[Steve Fink [:sfink] [:s:]]

Attachment: Add an "oops" command to do the same thing as qbackout with real commits

I suspect this will fail if you don't have mq on your system at all (it still imports it, even if it only uses it if you run |hg qbackout| instead of |hg oops|.) But you don't need to have mq enabled in your .hgrc, at least. I can fix the rest later.

Also, I don't like the name "oops". It's just that "backout", "rollback", and "undo" are all taken. Suggestions welcome.

And note that |hg oops --apply| probably ought to just say "please use |hg graft -f| instead". But I haven't used this enough to know whether that's always what you want.

Comment 2

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

I'd be okay with a flag that extends stock 'backout' to do these things.

Comment 3

[Ed Morley [:emorley]]

Comment on attachment 8548476 [details] [diff] [review]
Add an "oops" command to do the same thing as qbackout with real commits

Review of attachment 8548476 [details] [diff] [review]:
-----------------------------------------------------------------

More of a rubber stamp, but can't see anything major after a quick skim through.

Thanks for sorting this :-)

Comment 4

[Steve Fink [:sfink] [:s:]]

(In reply to Wes Kocher (:KWierso) from comment #2)
> I'd be okay with a flag that extends stock 'backout' to do these things.

I probably would too, but that's actual work as compared to mutating qbackout. :-) Also, I'm not sure if people would be happy with the merge-based backouts or not. They make more sense in a number of ways, but they're also kind of annoying.

Comment 5

[Gregory Szorc [:gps]]

I, too, vote for extending `hg backout`. It might also be possible to change the default behavior on repositories that are known to be Firefox repositories. The firefoxtree does something similar - changing the defaults of `hg push` when operating on a Firefox repository.

But I'm not going to block progress. We can always implement something marginally better later.

Comment 6

[Gregory Szorc [:gps]]

Comment on attachment 8548476 [details] [diff] [review]
Add an "oops" command to do the same thing as qbackout with real commits

Review of attachment 8548476 [details] [diff] [review]:
-----------------------------------------------------------------

::: hgext/qbackout/__init__.py
@@ +253,5 @@
> +    be one changeset queued up for each backed-out changeset.
> +
> +    The --apply option will reapply a patch instead of backing it out, which
> +    can be useful when you (or someone else) has backed your patch out and
> +    you want to try again.

We should be steering people towards `hg graft --force` for cherry-picking commits in history. https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

Please don't get too attached to this :)

Comment 7

[Steve Fink [:sfink] [:s:]]

http://hg.mozilla.org/hgcustom/version-control-tools/rev/7cae51b9c0c2 - landed patch
http://hg.mozilla.org/hgcustom/version-control-tools/rev/de45a9c027d4 - removed |hg oops --apply|

(In reply to Gregory Szorc [:gps] from comment #6)
> We should be steering people towards `hg graft --force` for cherry-picking
> commits in history.
> https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/
> common.html#revive-a-commit-that-was-backed-out

Agreed. So I just pushed an additional change that removes the --apply option from |hg oops| and updates the documentation to point to |hg graft -f| instead.