I'm doing a Mercurial rebase (induced by hg histedit) and I reach a conflict where I realize, actually, I should have dropped this patch. In git, I would have just done git rebase --skip. Is there an equivalent in Mercurial?
If you realize you should have dropped it, then the safe bet would be to do hg histedit --abort, then redo hg histedit and select drop for that changeset.
The only downside is losing progress on any other changeset conflicts already resolved in the same operation. To avoid that, there's hg histedit --edit-plan that allows changing the changeset to drop, and then use hg histedit --continue. But the current conflict still has to be resolved first, so for example hg resolve --all --mark could be done first. But I think this depends on the details of the current situation and gets much more complex and risky, and in most cases is probably not worth the trouble.
Related
In our workflow we are using Mercurial mq for our development the default branch. However, when we need to merge another branch into the default, what is the best practice to apply these patches on top of the merged default?
Obvious (ugly) way: pop all patches, merge branch then push all patches and fix all the .rej files...
Correct way should be to use rebase somehow but not sure what's the correct workflow.
Any ideas?
I think hg rebase --mq might do what you want. If not, try this:
hg rebase -s qbase -d default
The rebase command itself is aware of Mercurial Queues, at least in semi-recent versions of Mercurial.
See the rebase documentation, mention of this feature in the MQ documentation, and somebody's blog post.
In short, you can rebase applied MQ patches like you would any other set of changes, and rebase is smart enough to make sure they remain as MQ patches afterwards.
I've accidentally committed bunch of files locally, but didn't pushed.
So basically what I want to do is to remove this my commit, then push some other changes.
I can remove the commit by Backout-ing, then I've to commit locally so it is actually removed locally.
So my question is following, if I do a push, will my accidental commit and its corresponding revertion log be visible publically ?
It sounds like hg rollback is the command you want.
hg backout <REV> creates a new commit that reverses the changes made in <REV>. Both the original commit and the backout commit will remain in your history. This is one of the few options you have to fix a bad commit after you have pushed it to a public location.
However in this case you have not pushed to the public yet, so there are better solutions.
If the bad commit is the last commit that was done (i.e. your tip) then you can use hg rollback (under the Repository menu in TortoiseHg). This command is like "undo" for commits.
If the bad commit is elsewhere in your history (but still has not been pushed to a public repo), you can also use the mq extension to rewrite that part of your history.
You could use hg strip -r . --keep instead of hg rollback. hg backout would be necessary only if you had pushed your commits.
The simple answer to your question is Yes.
If you perform a Backout, then it will show up in your history.
You want to perform a Strip, as previously suggested.
This is an extension to mercurial.
https://www.mercurial-scm.org/wiki/StripExtension
I am aware that rollbacks can remove commits from the latest changeset in a local repository. However, is it possible to remove all the latest commits since the previous push without having to re-clone the share repository?
You can use the hg strip command, part of the mq extension:
hg strip REV
This will remove that revision + all its descendants.
Before you try this, make a copy/clone of the repository to experiment in.
You could make a new repo with hg clone:
hg clone -r last_good_changeset localrepo newlocalrepo
If you are using mercurial eclipse, you can rollback once, then shelve those changes, then export the multiple sequential commits as patches, strip those commits, then import those patches in the same order, so in case you had conflicting patches, they overwrite each other in the desired way.
Finally you can unshelve your first rollback. This achieves the same effect as if you were rolling back more than once.
If you do an hg pull and then an hg update (or an hg merge), is there a way to back this out? Ie: revert your repository to the state prior to doing the hg pull?
I believe you can do hg update -r n where you would specify the changeset prior to the pull as n. Though I'm guessing this will still leave the changesets in your repository but this isn't really what we want. ??
hg strip will remove revisions from a repository. Like all powerful commands, its dangerous, so be careful.
https://www.mercurial-scm.org/wiki/StripExtension
Also see:
https://www.mercurial-scm.org/wiki/EditingHistory
If you catch your mistake immediately (or reasonably soon), you can just use hg strip REV to roll back the latest (one or more) changes. ...
Ok, you can't rollback because you've done a commit. What you can do is use 'hg strip' which is part of mq (after 2.8 strip is in it's own extension), or use mq to remove the changes. Either way I suggest you do everything on another clone, just in case.
To do strip, update to a revision that you want to keep, and then
hg strip <REV>
where <REV> is the first revision you want to remove. It will remove that one and all decendents (including your merge commit).
Alternatively you can
hg qnew (if you don't already have a patch queue)
hg qimport <REV>
which will import a single revision into the patch queue. You can then add more, and then use the mq commands to edit, rearrange, delete, or whatever you want to do with those revisions. qdel deletes the current patch.
Edit: Obviously, you'll need to enable the MQ extension for both of these, unless you're using 2.8 or later. In that case strip is in the strip extension, and mq in the mq extension. Both are shipped with the standard installation.
hg --rollback can be used to undo the last transaction so as long as your hg pull is still the most recent transaction then you can use that. This command should be used with care though. See here for some more details.
you can:
hg update -C <version>
see the mercurial FAQ.
If you want to remove all traces of the pull form your history then you need to use an extension as Bert F suggests (the philosophy in mercurial is to never change history)
if you dont mind history containing your mistake you have two slightly different options hg update -C -r which will create a new branch at the version you specify or hg revert -r which will stay on the same branch but create a new uncommited change undoing everything.
hg backout tip seem to also revert all your files back to the older version. Is there a way to change it back to EXACTLY like before the commit -- that is, with several files "Modified" but uncommitted -- essentially, as if the "commit" was never done?
(hg rollback is said to be very bad and usually shouldn't be done for version control purpose)
hg rollback does exactly what you are asking for - it undoes the hg commit and you end up in the state you were before you committed.
Of course it's not really in the intention of a version control system to "lose" versions you already committed, but it's handy to revert an accidental commit.
Once you push, of course, there is no tool that will do what you want. That being said, if you have more than one changelist that you want to remove from your local history rather than just undoing their effect with hg backout, then you can use hg strip, which is available as part of the MQ extension package.
You can do the following to get your desired effect:
hg export tip > foo.patch
hg strip tip
hg import --no-commit foo.patch