I have a branch with a few revisions in it. I want to try making some code changes that require reordering and patching those commits with histedit, but I want to keep the original branch around in case it doesn't go well. How can I do that?
Example
Before:
master -> change 1 -> change 2 (branch A)
After:
master -> change 1 -> change 2 (branch A)
-> change 1 -> change 2 (branch B)
The integrated and recommended way to copy or cherry-pick commits from one branch to another is using
hg graft -r XX YY ZZ.
where XX YY ZZ etc. are the revisions to copy to your currently checked-out branch. By default they are committed, but you can also use the --no-commit flag so that you can edit changes. Or do it one-by-one and make additions using hg commit --amend.
Compared to exporting and importing it has the added benefit of using the configured merge programme, should a merge be required - but it will NOT be a merge, so no line of ancestors is established from the current commit to the one you copy from.
Related
We have three major releases a year, with co-responding branches: e.g. 2013A, 2013B, and 2013C. When we create each branch, it is started from default. Changes in each branch should only be merged forward, e.g. 2013A -> 2013B -> 2013C -> default. We have a push hook on the server that checks if a pushed merge is in the wrong direction, i.e. default -> 2013C, 2013C -> 2013B, etc.
We also have team-specific branches, some of which are working on features for a release, and others which are working on the next release, e.g. default. While a team is working on a release, they merge to/from the release branch. When the team is ready to work on the next release, they start to merge to/from the default branch.
The other day we had a situation where a new developer merged default into his team branch before the team was ready to move on to the next release, then merged the team branch into a previous release, i.e. default -> TeamBranch -> 2013B. Unfortunately, our hook didn't take this situation into account.
Essentially, this is what happened:
2013B A---o---o---o---o---B---o
/ \ / \
Team / o---o---o---C---o---o
/ / \
Default D---o---o---o---o---o---o---o---o
A = Creation of 2013B branch
B = Merge into release branch
C = The bad merge. We want to detect and prevent these whenever we merge into a release branch.
D = The first common ancestor of the release branch and default.
So, I've re-written our hook to check that when a change is merged into a release branch, it doesn't merge backward. For each merge into a release branch, I check that there aren't any ancestor merges from a forward branch. Here's the revset query I'm using:
> hg log -r "limit(descendants(p1(first(branch('2013B')))) and reverse(p2(ancestors(branch('2013B'))) and branch('default')),1)"
This works. However, we have a large repository (111,000+ changesets,) and the check takes 30 to 40 seconds. I wanted to know if there is a quicker/faster/more efficient way of writing my revset query, or another approach I'm not seeing.
I sent this same question to the Mercurial mailing list and received an answer. The branch() query is the performance bottleneck. It causes Mercurial to unroll all the changesets on a branch. Mercurial doesn't cache the results of this, so each call will unroll changesets.
Instead of using branch() I switched to using descendants() and ancestors():
limit(children(p2(2013BBaseline:: and ::2013B and merge()) and branch(default)) and reverse(::2013B))
p2(2013BBaseline:: and ::2013B and merge()) and branch(default) grabs the second parent (the incoming branch) for all merges between the start of the 2013B branch and its head, and returns just those on the default branch. [1]
The clause above is then wrapped with children() to go back down to the children of that parent.
and reverse(::2013B) then gets the children that are ancestors of the 2013B branch, i.e. the bad merge(s).
limit() then returns just the first of those bad merges.
The query above takes about 1.5 seconds.
Thanks to Matt Mackall for suggesting the solution.
2013BBaseline is a tag which identifies the changeset in the default branch from which 2013B branch was created, otherwise I would have had to replace 2013BBaseline:: with:
p1(first(branch(2013B)))::
to discover the release branch's baseline, and that is not very performant.
To detect the merge C, you should be able to use
$ hg log -r "parents(branch(Team) and merge()) and branch(default)"
This gives you changesets on default that were merged into Team. If there are any, then someone merged into their team branch by mistake. I think you need to attack this from the point of view of the team branch: you cannot forbid merges to/from the release branch since some of them will be legitimate.
If your team branches follow a consistent naming scheme (they should), then you can use a regular expression with the branch() predicate to select them. Something like
$ hg log -r "branch('re:team-.*')"
would match branches starting with team-.
I've got a mercurial repository. It was on rev A. I made some changes, committed (to rev B), and pushed. However, later, I realised I didn't want to make those changes. I updated back to rev A, and made some alternative changes, to rev C.
C
| -
| B
|/
A
However, now I can't push rev C, because it complains that it would create a new remote head (which it would). How do I make the remote mercurial simply forget about rev B and all the changes therein, so I can push rev C and carry on from there?
Editing History is hard. Once you push a changeset to a public repository, it can no longer be easily pruned from the history.
The most direct solution to your problem is:
hg update <tip of branch you want to forget>
hg commit --close-branch -m "close unwanted branch"
hg update <tip of branch you want to keep>
Push all your changes. As you noted, you will need to use --force since multiple heads on the branch now exist.
If you really need to prune the branch, then read EditingHistory again. If it still seems feasible, you can use one of the methods described in PruningDeadBranches.
Personally I'd close the branch and force the push (as Tim Henigan describes), as it leaves the DAG in a state which is truthful. There is another option though. Doing a dummy merge. This is a merge, but one where you ignore the incoming changes.
hg update C
hg -y merge --tool=internal:fail B
hg revert --all --rev .
hg resolve -a -m
hg ci
The end result is
M
|\
C |
| |
| B
|/
A
... but M doesn't contain any of B's changes.
Use the backout command to reverse the B change.
hg up B
hg backout B
Now, you're working directory is in the same state it was before B, which I'll call A'.
After you backout, make your real change and commit. This is what your history will look like:
C
|
A'
|
B
|
A
Mercurial branches are permanent and registered in commit objects themselves. There are some (not too easy) methods for closing and/or removing branches, mainly listed here. I have even already used some of them before. Note that those are somewhat desperate solutions for people who did use branches thinking they can be temporary.
However, if you really want temporary branches, use bookmarks.
Other people have some good answers for getting rid of 'B', but just to put it out there you can always do:
hg push --rev C
which will push C but not B and not complain about new heads.
We have switched to Mercurial recently. All had been going well until we had two incidents of committed changes going missing. Examining the logs has not made us any wiser.
Below is an example. The files committed at (1) revert to a previous state at (2) even though those files are not mentioned in the merge.
What can I check to understand why the files reverted?
There are three interesting changesets in this graph that can influence the (2) merge:
Teal changeset: not shown, but looks like it's just below the graph. This is the first parent of (2)
Blue changeset: number five from the bottom, labelled "Fix test". This is the second parent of (2).
Common ancestor of the parents: also not shown, will be further below. Strangely, it looks like the teal changeset could be the common ancestor, but Mercurial will now allow you to make such a degenerate merge under normal circumstances.
When Mercurial does a merge, these are the only three changesets that matter: the two heads you merge and their common ancestor. In a three-way merge the logic is now:
ancestor parent1 parent2 => merge
X X Y Y (clean)
X Y X Y (clean)
X Y Y Y (clean)
X Y Z W (conflict)
Read the table like this: "if the ancestor was X, and the first parent was also X and the second parent was Y, then the merge will contain Y". In other words: a three-way merge favors change and will let a modification win.
You can find the ancestor with
$ hg log -r "ancestor(p1(changeset-2), p2(changeset-2))"
where changeset-2 is the one marked with (2) above. When you say
The files committed at (1) revert to a previous state at (2) even though those files are not mentioned in the merge.
then it's important to understand that "a merge" is just a snapshot that shows how to mix two other changesets. The change made "in" a merge is the difference between this snapshot and its two parent changesets:
$ hg status --rev "p1(changeset-2):changeset-2"
$ hg status --rev "p2(changeset-2):changeset-2"
This shows how the merge changeset is different from its first and second parent, respectively. I'm sure the files are mentioned in one of those lists — unless the merge isn't the culprit after all.
When you examine the three changesets and the differences between them, then you will probably see that someone has to resolve a conflict (the fourth line in the merge table above) and picked the wrong file at some step along the way.
The merge at 2 is between a very old branch (dark blue, forked from the mainline/green branch just after commit 1) and an even older branch (light blue, hasn't been in sync with mainline since before commit 1)
It seems likely that the merge at 2 picked the wrong version of the file - can't tell from here if that was the tool picking the wrong version of the file, or the user manually selecting the wrong version.
Edited to add:
To help track down exactly what changed at 2, you can use hg diff -r REV1 -r REV2, which will show you the line-by-line differences between any two revisions.
When you know that the badness was introduced sometime between point 1 and point 2, hg bisect may help you track down the exact source of the badness:
hg bisect [-gbsr] [-U] [-c CMD] [REV]
subdivision search of changesets
This command helps to find changesets which introduce problems. To use,
mark the earliest changeset you know exhibits the problem as bad, then mark
the latest changeset which is free from the problem as good.
Bisect will update your working directory to a revision for testing
(unless the -U/--noupdate option is specified). Once you have
performed tests, mark the working directory as good or bad, and bisect
will either update to another candidate changeset or announce that it
has found the bad revision.
I have a local mercurial repository (for now) within which I have already made several commits, each commit is a self contained bug fix. Is it possible to pick which of the bug fixes (commits) I want to be included when it is time to build a release version of my application.
To elaborate, assuming A, B, C, D, and E are commits I have already done to my repository and each of them relates to a bug fix like so:
A <- B <- C <- D <- E <- working dir
I need to be able to for example pick which of the bug fixes will go into the release version (this depends on the time allocated for deployment as well as testing outcomes). So for example I might get a report saying the release should only contain bug fixes A, C and D.
Is it possible to construct a release version containing only the A, C and D commits (Keeping in mind that each commit is self contained and does not depend on the other commits to actually be there)?
Probably having a branch for each bug fix and then merging into a release branch is the easiest way to accomplish this (or is it not?), but the current situation at hand is as described above with no branches.
This isn't the normal work mode of Mercurial (or git). A repository can only contain a changeset if it also contains all of that changeset's ancestors. So you can't get D into a repo without also having A, B, and C in there.
So here's:
What you Should have Done
Control the parentage of your changesets. Don't make C the parent of D just because you happen to have fixed D after C. Before you fix a bug hg update to the previous release.
Imagine A was a release and B, C, and D, were all bug fixes. If you do a loop like this:
foreach bug you have:
hg update A
... fix bug ...
hg commit
hg merge # merges with the "other" head
then you'll end up with a graph like this:
---[A]----[B2]--[C2]--[D2]----
| / / /
+-[B] / /
| / /
+-----[C] /
| /
+---------[D]
and now if you want to create a release with only, say, B and D in it you can do:
hg update B
hg merge D
and that creates a new head that has A + B + D but no C.
Tl;Dr: make a change's parent be as early in history as you can, not whatever happens to be tip at the time.
What you can do Now
That's the ideal, but fortunately it's no big thing. You can never bring exactly D across without bringing C (because C's hash is part of the calculation of D's hash), but you can bring the work that's in D into a new head easily enough. Here are some ways, any of which will work:
hg export / hg import
hg transplant
hg graft (new in 2.0)
hg rebase (only possible if you haven't yet pushed)
Any of those will let you bring that patch/delta that's in D over -- it will have a different hash ID and when some day you merge D in for real (using merge) you'll have duplicate work in two different changesets, but merge will figure it all out.
If this was my tree and it hasn't been pushed anywhere, I'd (assuming an empty patch queue and MQ enabled):
hg qimport -g -r B: # import revisions B and later into mq as "git" style patches
hg qpop -a # unapply them all
hg qpush --move C # Apply changes in C (--move rearranges the order)
hg qpush --move D # Apply changes in D
hg qfin -a # Convert C & D back to changesets
hg push <release server> # Push them out to the release branch
Then you can hg qpush -a; hg qfin -a to get B & E back into changesets.
Final Result:
---A---C---D---B---E
Advantages:
Nobody needs know you didn't do things in this order to start with (evil grin)
You could modify any of the change-sets whilst doing this
Alternatively, with graft in 2.0:
hg update -r A # Goto rev A (no need to do anything special for A)
hg graft C # Graft C on to a new anonymous branch
hg graft D # Graft D
This will give you
---A---B---C---D---E
\
--C'--D' <-You are here
An hg push -r D' should just push the new, cherry-picked, head.
You can then hg merge to get one head again with B and E included.
Advantages:
Non destructive, so true history is kept, and no chance of loss if you muck up
hg tags the new changesets with the hash of the original version, so totally trackable
Probably a little simpler.
While it's somehow strange way and release-policy, you can do it in different form. You have to manipulate with two main objects: changesets and branches
Version 1
You use two branches (default + f.e "release 1.0"). Default branch is mainline of your work - all changesets commited to this branch. At release-time, you branch first needed-for-release changeset into (new) branch, transplant or graft rest of needed in release changesets from default to this branch, head of release 1.0 will be prepared for release this way.
Next release will differ only in new branch name
Version 2
One branch used, MQ extension added. Variations:
all changesets are MQ-pathes and only needed for release are applied to repo
changesets are changesets, only unwanted for release converted to mq-pathes, later qfinish'ed and returned to repo
Take a simple example: I'm working on the default branch, have some changesets committed locally, and I pulled a few more from the master repository. I've been working for a few days in my isolated local repository, so there's quite a few changes to merge before I can push my results back into master.
default ---o-o-o-o-o-o-o-o-o-o-o (pulled stuff)
\
o----o------------o (my stuff)
I can do two things now.
Option #1:
hg pull
hg merge
Result #1:
default ---o-o-o-o-o-o-o-o-o-o-o
\ \
o----o------------o-O
Option #2:
hg pull
hg update
hg merge
Result #2:
default ---o-o-o-o-o-o-o-o-o-o-o-O
\ /
o----o------------o
These two results look isomorphic to me, but in practice it seems that option #2 results in way smaller changesets (because it only applies my few changes to the mainline instead of applying all the mainline changes to my few).
My question is: does this matter? Should I care about the direction of my merges? Am I saving space if I do this? (Doing hg log --patch --rev tip after the merge suggests so.)
They're (effectively) identical. You see a difference in the hg log --patch --rev X output size because log shows the diff of the result and (arbitrarily) its 'left' parent (officially p1), but that's not how it's stored (Mercurial has a binary diff storage format that isn't patch/diff based) and it's now how it's computed (p1, p2, and most-recent-common-ancestor are all used).
The only real difference is, if you're using named branches, the branch name will be that of the left parent.
There is also a difference if you are using Bookmarks. When doing a merge, the branch that you are is the branch that is receiving the changes, so the new changeset will be part of that branch. Supose you have this situation:
default ---o-o-o-o-o-o-o-o-o-o-o -- Head: Rev 200
\
o----o------------o -- Head: Rev 195, Bookmark: my-stuff
If you merge Rev 200 into Rev 195, the bookmark my-stuff will move on to Rev 201, as you are generating a new changeset in the same branch that has the bookmark.
On the other hand, if you merge 195 into 200, you are generating a changeset in the branch that don't have the bookmark. The my-stuff bookmark will remain in Rev 195.