I've got a (remote) Hg repository with a couple branches. I want to verify that branch A has every changeset that branch B has (it may have more, and that's OK).
Is there an easy way to do this with just hg?
I can write a little shell script to do it, but it seems like the sort of thing that might come up a lot, so maybe there's an easy built-in way.
This will show any ancestors of changeset b which are not an ancestor of changeset a:
hg log -r "ancestors(b) and not ancestors(a)"
This should show you which changes still need to be merged from B to A if you give the head of branch B for b, and the head of branch A for a.
Related
Backout works by applying a changeset that's the opposite of the
changeset to be backed out. That new changeset is committed to the
repository, and eventually merged.
https://www.mercurial-scm.org/wiki/Backout
How can I backout without commiting the changeset? I just want the changeset reverted in a working directory.
Try hg backout --no-commit REV
This will perform the backout but leave the changes uncommited.
Assuming you have already committed a new changeset but not yet pushed it; let's say your history looks like this:
A--B--C--★
where C is the recently committed changeset you wish to do away with, but leave its modifications in the working folder. And ★ is the working directory (not an actual changeset itself).
There is more than one way to do this. One approach is the following...
hg up B
This leaves your history looking like this:
A--B--★
\
C
Then do
hg revert -r C
which in effect copies whatever changes were in C into your working folder.
Then you could do (optional)
hg strip C
which eradicates C from history:
A--B--★
An advantage of this approach is that it removes C entirely, like it never existed.
(I mentioned that using strip is optional in this sense: if you did leave C in place, it causes little harm. And you'd never need to push it if it is marked secret. But personally I would clean it up by stripping.)
We have a very unfortunate situation where a new feature branch was made from a second, unrelated feature branch that had been put on hold rather than from default. There's multiple changesets within both feature branches and while most changed files are unrelated several high level project files that have edits on both branches. Default has also had several updates and merges during this time too. Thankfully the intermediate feature hasn't been updated concurrently with the new feature. I've looked into various commands and options available and lost how to best fix this situation. The tree currently looks roughly like:
Default -- Various edits and merges -- tip
\
\-- Named Branch 1 (15 changes) -- Named Branch 2 (30 edits)
I want to get to a point where default has the changes from Named Branch 2 but none from Named Branch 1. I also want a branch that has the changes from Named Branch 1 available for when we return to this feature.
I suspect there's no nice easy way to do this, and there's going to be some messy parts in the history, however I am at a loss at how to start going about this task.
hg graft can cherry-pick changesets from one branch to another. Update to the destination branch, then graft the revisions you want to copy by running, for example:
hg graft 8 9 10
Conflicts will be handled using the normal merge process.
If you use TortoiseHg, select the changesets to graft to the current selected changeset, then right-click and select Graft Selected to local...:
Result:
Since you want to move the entire branch 2, you could consider using rebase. Make a clone of the repository and try this:
hg rebase --source <first branch2 rev> --dest <new parent in default> --keepbranches
This will in principle transform the history to what it should have been. However:
You may have to resolve conflicts arising when <first branch2 ver> gets moved to a new parent.
Since rebase rewrites history, you'll have to get everyone to cooperate in synchronizing their repositories. Whether that's feasible or worth the trouble in your case I can't say, but it's not that difficult: Assuming everyone has pushed any changes in branch 2, they can pull the new history and then get rid of the obsolete version of branch 2 with hg strip:
hg strip <first branch2 rev>
I have a bunch of commits, say A, B, C, D, and I want to keep B, C, and D, and make a commit that is (BCD)⁻¹. What's the easiest way to do this, if I have many commits that I want to undo at the same time?
(I seem to recall seeing a stackoverflow question about this that suggested that I hg update to A, and then call hg commit with some arguments, but I can't seem to find that question now.)
It sounds like you are looking for backout. See:
hg help backout
I don’t think it can back out multiple commits in one go, so you have to back them out individually:
hg backout D
hg backout C
hg backout B
This will create three commits on top of D that are the reverse of D, and C, and B. If you want to combine these commits into one changeset, you can fold them using rebase --collapse or one of a number of other extensions (e.g. the histedit or mq or collapse extensions).
If you don’t want to back out the individual changes but do it all in one go, you could do the following:
hg update A
hg debugsetparents D
hg commit -m "revert B-D"
It’s ugly, but it works. However this does not record renames in reverse. To be honest though, I wouldn’t recommend doing this, if you need to back out so much that individual backout commands are too much trouble to type it makes me wonder if backing out is really what you should want to be doing for that particular case.
Alternatively, you could do as Jim and Rafael suggested, and decide that B, C and D are on a branch, and update back to A and continue committing there (splitting off history at that point). This may be more appropriate.
The easiest way:
You are in changeset D and you want to terminate that branch
hg commit --close-branch -m "Branch closed"
Now, just go to changeset A and continue your work commiting new stuff
hg up -r A
... change stuff ...
hg ci -m "New stuff"
The branch that has B, C and D will be there, but it will be terminated, it won't show in hg heads. It will be an inactive branch.
That's easy to do and expressive too. If you look at the graph you'll see a separate branch that was closed and the "official" branch will go on. Much better than having those revert and backout changesets making noise in your branch.
You've answered your own question, update back to A and just continue from there. If you need to make a new head at that point, you'll need to make a change to some file or the other as described here: How can I force mercurial to accept an empty commit . A mail thread linked to from that post describes a way to use MqExtension to remove BCD (unless you've pushed them):
What if one branch has two heads? I came to this situation weeks ago for some reason I didn't merged them back then and just continued developing on one head. Now I want to get rid of the other head. What should I do? Should I just merge them after so many changesets?
So you have this:
o--o--o--A--B <- older unnecessary head
\
1--2--3--4--5--6 <- newer ‘good’ head
...and you don't need A and B, absolutely, 100% sure. If you aren't sure, and there are possibly salvageable things in A and B, better merge the heads to combine the changes. As Aaron said, Mercurial is good at it.
Now you have two options:
get rid of the old head, or
do a dummy merge of two heads that ignores head B.
If changesets A and B are present in other repositories you don't control, e.g. if other people pulled A and B into their repositories, or you pushed A and B to a public repository (say, Bitbucket), then you've released A and B into the wild, and can't get rid of them. You should do a dummy merge:
$ hg up 6
$ hg --config ui.merge=internal:local merge
This will ignore any changes from A and B when merging.
If, on the other hand, A and B are private, you can either strip them:
$ hg strip A
(Rev A and descendants stripped; enable the MQ extension to make strip available.)
Or, make a new clone of your repository without changesets A and B:
$ hg clone myrepo myrepo2-clone -r 6
(Only rev 6 and ancestors added to the clone.)
A head is created if you commit some changes (add a changeset to an existing changeset). If that happens several times for the same changeset, then several heads are created. This is nothing unusual or bad.
The usual solution is to merge them. Mercurial is very good at merging. Chances are that the result will still compile and run without any manual work.
Just run hg merge and then hg status and hg diff to see what changed between the two. If you like the result, commit it. If you don't like it, update to either head to clean your workspace.
To get rid of a head, the docs explain how to do that.
Using MQ, you can also turn the second head into an independent branch (so you can keep it around but it won't bother you). See this answer: How can I create a branch for a non-tip revision in Mercurial?
If you need to keep the changes on the old branch, you should merge them, and it should not be a problem.
My coworker accidentally made two commits in the default branch instead of creating new his own development branch.
How can I change this situation and moves these two commits to a new branch?
Imagine the following scenario:
D
|
C
| "I want to move C and D here"
B/
|
A
Steps:
hg update B
hg branch "mybranch"
hg commit --message "Create my branch"
hg update mybranch
hg graft -r C
hg graft -r D
hg strip -r C (this should be the revision C had originally)
The strip command is provided by an extension that you need to enable. You can follow a guide on how to enable it on the Mercurial Wiki.
hg update default
A major question
Have the accidental commits reached other repositories or is it just in his own? If so, you can skip to the section below 'Maybe the cat is still in the bag' otherwise you may have a fair bit of work to do.
You are not alone
See here for more discussion on how to correct the problem elsewhere on Stack Overflow. What is described is the 'proper' way to to it
export a patch
create the branch
import the patch
delete the earlier commits.
Maybe the cat is still in the bag
If the changes are only in the local copy, then a simpler solution is to
create the new branch
switch to it
merge the changes onto that either with your fav merge tool (go Meld) or with hg graft
use the hg strip command to delete the changes on the old brach
push the changes to the world
pretend like nothing ever happened, whistle a happy tune ...
The two answers above are both correct but, assuming one has not yet pushed the commits, there's a third way.
I just successfully used the rebase command to move a string of commits to a topic branch I had forgotten to create in the first place.
I first updated to the revision from which I wanted to create the branch on which my commmits were supposed to be, then I rebased the earliest of my commits from the wrong branch on this new one and ta-da, done.
Takes more time to explain it than to do it with TortoiseHg or even the command line, really.