Closed
Bug 1121211
Opened 8 years ago
Closed 8 years ago
qbackout without mq
Categories
(Developer Services :: Mercurial: qbackout, defect)
Developer Services
Mercurial: qbackout
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: sfink, Assigned: sfink)
Details
Attachments
(1 file)
14.33 KB,
patch
|
emorley
:
review+
|
Details | Diff | Splinter Review |
I've wanted qbackout's functionality but using real commits. See also bug 1117632.
Assignee | ||
Comment 1•8 years ago
|
||
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.
Attachment #8548476 -
Flags: review?(emorley)
I'd be okay with a flag that extends stock 'backout' to do these things.
Comment 3•8 years ago
|
||
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 :-)
Attachment #8548476 -
Flags: review?(emorley) → review+
Assignee | ||
Comment 4•8 years ago
|
||
(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•8 years ago
|
||
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•8 years ago
|
||
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 :)
Assignee | ||
Comment 7•8 years ago
|
||
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.
Assignee | ||
Updated•8 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•