I have two named branches v1 and v2.
I merge a new changeset abc from v1 into v2. The merge changeset m is in branch v2.
I notice there's a small typo in abc.
In v1 I amend abc -> abc'.
I execute hg evolve and get a new merge changeset m'.
All this is as expected. But now m' is in v1 instead of v2. That is unexpected and not what I want.
What should I have done different? What can I do to fix this now?
Indeed it sounds unexpected and you probably should report that very issue to the evolve developers.
On the matter at hand: You can manually merge m' into v2, and manually obsolete or strip the unneeded changesets.
EDIT to add: If you want to fix it in-place, you can resort to the debug commands. Check out hg help debug. Use them with great care and only when you have a full copy of the repo. I haven't tried, but maybe hg debugsetparents can be of utility.
Related
Let's say I have anonymous branches AA and BB.
In branch AA there is a changeset CC which I'd like to merge into BB, without bringing in all its parents.
Doing this would work:
hg diff -c CC >>CC.diff
patch -p1 <CC.diff
However, I'd lose the information that this the same changeset as CC, I'd just be creating a new one which happens to do the same thing.
Is there a more repository-friendly way to go?
You can cherrypick changesets using the hg transplant extension.
transplant is fine when you cannot do a full merge for some reason. However, it is not recommended to rely on it in your daily workflow due to its side effects.
EDIT: This functionality is a core feature (hg graft) in Mercurial since version 2.0.
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.
I've been using Mercurial for a few weeks now and don't understand why when Mercurial comes to merge committed changes from two repositories it does it in the working copy?
Surely the merge could happen without the use of the working copy removing the need to shelf changes etc.
It just doesn't seem necessary to involve the working copy. Am I missing something?
There is only one working copy per repository, by definition:
The working directory is the top-level directory in a repository, in which
the plain versions of files are available to read, edit and build.
Unless your file system descends from Schrödinger's cat, you cannot have two versions of the same file at the same time, thus you cannot have two working copies.
Nevertheless, it's indeed theoretically possible to use something like a ephemeral clone (per #Ry4an) to act as the working copy of a merge, resolve conflicts there, commit, then make it disappear. You'd get a beautiful merge changeset and your intact working copy.
I can think of several ways to achieve this:
Petition hg team to do it in core
Write an extension to implement the ephemeral clone or some other way
Shelve with a temporary changeset
Shelve with MQ
I would strongly recommend #4, as I would for almost all workflow scenarios. It took me a few good days to grok MQ, but once I did I've never had to turn back.
In an MQ workflow, your working copy is always the current patch. So for the merge situation you would do:
hg qrefresh
hg qpop -a
hg update -r<merge first parent>
hg merge [-r<merge second parent>]
hg commit
hg update qparent
hg qgo <working copy patch>
You don't have to pop all patches in #2. I always do that whenever I need to deal with real changesets to avoid mixing them up with patches.
Solution #3 is really the same as #4, since a patch is a temporary changeset by definition (this is really the only thing you need for understanding MQ). It's just different commands:
hg commit -A
hg update -r<merge first parent>
hg merge [-r<merge second parent>]
hg commit
hg update -r<working copy changeset parent>
hg revert -a -r<working copy changeset>
hg strip <working copy changeset>
If you want to keep the working copy changeset and continue to commit, simply update to it in #5.
From your question it seems like you already know #4 but don't like shelving. I think shelving is good because merging is a fundamentally different task than coding (changing working copy), and shelving makes the context switch explicit and safe.
I didn't write Mercurial, so I can't say why they did it that way, but here are some of the positive results of that decision:
you can look over the results of the merge before you commit it
you can edit the results of the merge before you commit it
you're encouraged to commit frequently
If you really want to do a merge and have stuff in your working dir that you can't bear to commit don't bother with shelve just do:
cd ..
hg clone myrepo myrepo-mergeclone
hg -R myrepo-mergeclone merge
hg -R myrepo-mergeclone push myrepo
On the same file system clone is near instantaneous and uses hardlinks under the covers so it takes up almost no space past that of the temporary working copy.
As mentioned in the chapter "Merge" of HgInit:
The merge command, hg merge, took the two heads and combined them.
Then it left the result in my working directory.
It did not commit it. That gives me a chance to check that the merge is correct.
Such check can include conflicts in merge, that the user has to review:
In KDiff3, you see four panes
The top left is the original file.
Top center shows Rose her version.
Top right shows Rose my version.
The bottom pane is an editor where Rose constructs a merged file with the conflicts resolved.
So you need a working directory (a view for the merge) in order to resolve fully a merge.
I tried to merge two heads in Mercurial. After merging, I didn't commit and did some more changes. Then I tried to commit and got the following message:
abort: cannot partially commit a merge (do not specify files or patterns)
I'm using TortoiseHG as visual shell, and Beyond Compare for comparing and merging. And I'm relatively new to all of them.
What should I do to finish commit successfully?
Mercurial/TortoiseHg is correct in telling you that you should not partially commit a merge. Partial means that you do not commit all files at once.
The underlying reason for this message is that is gives you the wrong results. When you merge two changesets in Mercurial, you are creating a new changeset with two parent changesets. This merge changeset shows others how you want everybody else to combine the two changesets.
Let us imagine that you start with changesets A and B and want to merge them. This creates a graph like this:
... --- [A]
\
[M]
/
... --- [B]
Pretend that we added the line A! to a.txt in the A changeset and that we added B! to b.txt in the B changeset. Just two independent changes that does not conflict. If Mercurial allowed you to do a partial commit, then you could do this:
hg merge
hg commit -m 'Added A!' a.txt # creates M
hg commit -m 'Added B!' b.txt # creates M'
and the result is this graph:
... --- [A]
\
[M] --- [M']
/
... --- [B]
If you look at b.txt along the path B, M, M', then you will see that the line with B! was introduced in B, removed in M and reintroduced in M'!
This is not what you want from a merge changeset: a partial merge throws away changes from one branch just to introduce them again in a followup commit. Mercurial trusts you when you create M: it really believes that M contains the correct mix of A and B. In particular, if the B! line is removed in M, then it will remain gone when you merge M with other changesets.
So Mercurial is trying to protect you from creating a bad history by not allowing partial merges.
I think you have aliases in hgrc file. Try to remove [alias] section and commit again.
What should I do to finish commit
successfully?
One of the benefits of Mercurial (or git or any other DVCS) is that you can perform a commit at any point in your development process and it will be both fast and private. It will be fast because you should be committing to a local copy of the repository residing on your hard drive, and it will be private because no-one will see your change set until you push them to the server (or other master repository).
Therefore, to partially answer your question, the appropriate thing to do would have been to commit the merge without your addition changes, and then apply and commit your next wave of changes. If you are using TortoiseHG to peform the merge it will actually prompt you to commit the merge before leaving the GUI because this is the intended HG workflow.
That being said, I made some changes on a named branch (ie: new head), merged it back into the default branch, exited the TortoiseHG GUI without committing, made some more changes, and then committed with no problem. I will ask some clarifying questions below your original inquiry.
I had this problem because I had deleted some files. I reverted the files to restore them, then was able to commit. I then deleted the files and did a second commit.
I had the same problem and I was NOT specifying any files and using command-line.
The problem was the [default] section in my .hgrc
[defaults]
commit = -X project/web.config
So it added specific files to every commit-operation by default.
Review your defaults section for potential problems.
I had the same problem and the command I gave was
hg commit -m Merge with 1234
I figured it out after sometime that the commit message "Merge with 1234" has to be given in quotes as the command takes "with" and "1234" as file name params.
please check it in your case.
Is there a way to remove a from a remote changeset, or to remove an entire changeset?
I accidentely pushed a .war file to a remote repo and I want to remove it.
Mercurial tries very hard to keep your data safe, so you can generally not change history.
That being said, there are numerous extensions for Mercurial that allows you to quite easily change history anyway. There is a page on the wiki about editing history. That page also explains the consequences.
In your specific case, you have to ask yourself if others will have already pulled your changeset? If so, then even if you remove it, it will still exist in their clones and you might be better off with accepting the mistake.
If you decide to remove it, I suggest using hg clone to get a copy without it. This is the safe way since it will always leave behind a backup. If you pushed [z] to the remote repository:
[x] --- [y] --- [z]
and now want to remove it, then log into the server and do
hg clone -r y repo repo-without-z
Then repo-without-z will contain all changests up till [y] — that is, [z] will have been removed:
[x] --- [y]
You can then continue working and push a new changeset:
[x] --- [y] --- [w]
If I had pulled the [z] changeset already and now pull [w] I will see two heads in the repository:
[w]
/
[x] --- [y] --- [z]
This is not dangerous per se -- but people might be surprised. If I remove [z] from my clone I will end up with the same repository as you. But, as wrote above, this might be impractical if you have many users.
You can also use the MQ extension to strip the changeset away in-place. That way you wont make a new clone.
Finally, if you're certain that the push was the very last operation done on the server, then hg rollback can be used to remove the last transaction. But don't do this if you are the only one who can push to the repository, otherwise you might end up rolling back a different transaction.
If the repository is on Bitbucket, then you cannot log into the server. But Bitbucket has recently added a strip functionality to its web interface. Look for "Repository management" in the "Admin" section.
Bitbucket does offer you a bundle (backup) upon stripping, and this does not count against your quota. The reason why it appears to do so, is only because we haven't invalidated the cache key specifying how much space you use.
This is a bug in our system, and will be remedied. Until then, rest assured that the changeset has been removed, and the backup is free :-)
I used hg mqueue extension to edit history. It seems that it worked.
Thanks all.
I had a similar case where i want to remove a merged branch "A" changeset from "Dev" branch remotely using TortoiseHg:
Create branch AA from branch A's parent branch; its origin.
Merge A into AA (working directory) and make sure that option: "Discard all changes from the other revision" is checked.
Merge AA into Dev branch (with a commit message indicating that branch A changes were removed).
You'll see that branch A changes are no longer exist in Dev.