Short version of the question: Since I already have TortoiseHg, I right clicked on that file trying to see the merge conflict visually, but there is no way to see it?
Details:
To make a simple case of merge conflict, I hg init a repo on Win 7, and then clone it to another folder.
Now, in one working directory, i added the line "the code is 123", committed.
And in the other folder, i did an "hg pull" and "hg update"
Now, I go back to the first folder, and change "123" to "123abc", and then do an "hg commit"
And then I go to the other folder and edit "123" to "123xyz" over there, and do an "hg commit", and when "hg push", it says it can't.
So I try to use any visual tool to see how the conflict is like, but ... TortoiseHg doesn't seem to have any option to do that?
There isn't a conflict yet. Same as svn or cvs you need to fetch changes into the second repository before you can commit back to the first and it's this that creates the conflict. In the second repository, you need to
hg pull to fetch the 123abc change from your first repository; this'll be created in repoistory 2 as a new branch
hg merge to merge the changes - now there's a conflict that you need to resolve
hg commit to commit the resolution of the conflict
and now you can hg push.
Related
I have 3 commits which I pushed to the public repository accidentally. I want to revert to an older version (a version before these 3 commits happened) and make it the current code in our public repository.
I am using TortoiseHg,version 2.11.1
Option 1
You can use the strip option as mentioned in the command
hg strip is the command
This extension has to be enabled
Enable the extension by adding the following lines to your .hgrc or Mercurial.ini:
[extensions]
strip =
This option is only suitable if you have access to the central repository where your code is hosted and you have a small group in which you would know if someone have already pulled your changes.
Option 2
Another option would be to backout these 3 commits, Since you are using UI,I will attach a screen shot
Step 1: Right click the unwanted commit and you will see a backout option click that and the wizard wll guide you.
if its a merge that you are trying to backout then you have to select which branch to backout to.
Do the same for the 3 unwanted commits
Option 3
if you have many commits and if its in a named branch following these steps will provide a solution
1) Close the branch and update to the last good commit you want.
2) Reopen the barch from there by new commit (Named branch can have multiple heads)
3) use hg revert -r and commit
This will make the working directory exactly as the last good commit you need and ignore the inwanted commits. This will only work if the commits are in a named branch.
You can do it like this:
hg backout -r <rev>
hg push
This will backout to the <rev> revision (which should be the last correct commit). In other words, it will set your working directory into the same state as it was on the last correct commit and create a new commit with an explanatory message. Then you'll push it to the public repository so it's the current code again.
I am trying to do something very simple: create a new branch. But I messed up. Where did I make the mistake, and how do I fix it?
I am the only user of Mercurial. I had revision 54 committed and pushed to remote repository. I wanted to create a branch based on revision 53, so I updated my local copy to revision 53, made changes, and committed (ignoring the warning about "it's not the head"). Then when I am trying to push to remote repository, it says
abort: push creates new remote head
Maybe I needed to tell Mercurial that I want to create a new branch? If so, how and at what point?
Thanks!
You tell Mercurial that it can go ahead with
$ hg push --force
You need to force it since multiple (unnamed) heads are normally discouraged. The problem with them is that people that clone the repository wont know which one to use. But since you're the only user you can just go ahead and push.
The alternative is to use a named branch (with hg branch) and then you'll use
$ hg push --new-branch
to allow the creation of a new branch on the remote. Named branches have the advantage that they make it easy to distinguish the two branches. They have the disadvantage that they are permanent. Permanent means that you cannot remove the branch name from the changesets on the branch — the name is literally baked directly into the changeset.
Bookmarks provide a way to have non-permanent branch names, see hg help bookmarks.
Another reason for this error: probably there are some UNMERGED changes form the central repo in your default branch.
hg up default
hg merge
hg ci -m "Merge"
hg pus
I did this. Using TortoiseHg ... this is how I fixed it:
In settings, I enabled the Strip extension then right clicked the branch i did not want, Modified History - strip. If you have pushed, then it needs to be stripped from all other repositories, including workmates who have pulled your unwanted branch.
An alternative is to merge the unwanted branch into your main branch, but do not take any of the changes from that branch - I am unsure of how that mechanism works.
I have been happily using HgSubversion for awhile and today I forgot to add the --svn to the rebase command.
Now i get the dreaded unknown revision ''
Is there a way to recover from this?
You should be able to do "hg svn rebuildmeta" and then do "hg pull" and have it repair things.
Note: this is untested, so I'd work on a duplicate of the local repo in case it screws things up. My memory of the code suggests this will work.
I'd try using the transplant extension to fix this:
Re-clone the SVN repository to a new local repository.
Examine the history of the original repository and note which changes need moving
Transplant the changes from the old repository to the new repository
For example - fixing an hgsubversion repo called project:
> hg clone svn+http://svnrepo/project project-tmp
Then examine the log of your original project folder and do the following from the project-tmp folder:
> hg transplant -s ../project 1234
Where 1234 is the revision that you want to move over. Repeat this until all your revisions are copied.
When you're done you should be able to start using the new folder in place of the old folder by re-pulling from SVN, rebasing your changes and push them back (don't forget --svn)
If you see here, you'll see that I have:
CheeryTomatoe.Examples <--- I want to remove this.
CherryTomatoe
CherryTomatoe.Examples
https://bitbucket.org/sergiotapia/cherrytomato
How can I completely remove this from my repository? What command can I run?
In theory, you can edit the history (provided nobody has yet cloned your public repo), as described in:
Mercurial FAQ 4.14 and 4.15
Mercurial Wiki "Editing the History"
However, that is not the best way to work with Mercurial, so what you did in your third commit is better: hg rename:
See Hg book: "renaming file":
When you use the hg rename command, Mercurial makes a copy of each source file, then deletes it and marks the file as removed.
It is your initial commit.
Delete the repository and start over.
I want to completely delete a Mercurial commit as if it was never entered in the repository and move back to my prior commit.
Is this possible?
If it was your last commit and you haven't pushed it anywhere, you can do that with rollback. Otherwise, no. Not really. Time to change your passwords.
Edit: It has been pointed out that you can clone from an older revision and merge in the changes you want to keep. That's also true, unless you have pushed it to a repo you don't control. Once you push, your data is very likely to be very hard to get back.
You can try to remove mq info about your commit.
For this you need to go File->Settings->Extensions.
There check mq and restart gui.
After that just right click on unneeded commit and
ModifyHistory->Strip
To edit the history I would use the Histedit Extension extension.
hg histedit 45:c3a3a271d11c
However keep in mind this only makes sense in a situation where you have not yet pushed the commits to the public repository, you own the public repository and/or you can account for all the clones out there. If you receive the following error:
abort: can't rebase immutable changeset 43ab8134e7af
It means that Mecurial thinks this is a public changeset (see phases) that has already been pushed - you can force it to be a draft again doing:
hg phase -f -d 45:c3a3a271d11c
I encounter this fairly often. I make a commit and then pull to push. But then there is something incoming that makes my newly made commit unnecessary. A plain hg rollback isn't enough because it only undoes the pull...
This is the thing to do:
hg strip <rev>
Things are painless when you don't push your changesets anywhere.
If it's more than one commit and/or you already pushed it somewhere else, you can clone your repository and specify the last changeset that should be cloned.
See my answer here how to do this:
Mercurial: Fix a borked history
If you only committed locally and didn't push, you can just create a clone locally (as described in my link) and you're done.
If you already pushed to some remote repository, you would have to replace that with your clone.
Of course it depends if you are able (or allowed) to do this.
You can use "hg backout" to do a reverse merge basically. All options are discussed in the freely available book "Mercurial: The Definitive Guide":
http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html
If using tortoise you can use modify history > strip...
Yes. Unless I am mistaken, as of v2.3 (rel. 2012/08/01) you can use the HisteditExtension with a drop command to drop a commit, along with strip or backout to remove changes.
A simple Google search on the feature: https://www.google.com/webhp#q=histedit+drop
In 2022 I do use evolve extension. It is one of the best extensions for this purpose.
To prune unwanted changeset, if you for example did a quick hack to get the code working:
$ echo 'debug hack' >> file1.c
$ hg commit -m 'debug hack'
Now you have a proper patch you can do hg prune .:
$ hg prune .
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
working directory is now at 2a39221aaebb
1 changesets pruned
If you push the change to the remote repository you will find only obsolescence markers:
$ hg push
searching for changes
no changes found
remote: 1 new obsolescence markers
To check the changes to your local repo you can pull from the remote one:
$ hg pull
pulling from ssh://userid#server/repo
searching for changes
no changes found