I was doing pull with mercurial eclipse plugin. Dialog 'merge with two heads' appeared and it took a long time, nothing was happening, so I clicked again on 'merge with two haeds' but then it wouldn't show files with conflicts in 'Mercurial merge' view. It pulled changes, but can not resolve conflicts. Then I tried to do pull again, 'merge with two heads' appears but this time it says I have uncomitted changes that will be discarded so I said 'No' (I am scared I will lose my previously comitted changes). Can someone please give some advice? What shall I do?
You "should" be fine to discard the uncommitted changes; the failed merge would create "uncomitted changesets". I have had to do the same on failed merges before before by using hg update -C where the -C means "Clean it up and throw away all changes that aren't committed".
Regarding your fear of losing your committed changes: once you have committed your changes, it is very hard to get rid of them without hg extensions that let you edit history. So you should be safe. (You do have a backup plan in place, right?) If you hadn't committed important changes before you started the merge you only have yourself to blame! :)
To try to sort things out, you could clone the repo to an adjacent location, such as \repo2\ and verify that it has the changes you expect. You can also attempt the merge in \repo2\ first and only pull the merged changeset into \repo\ once it is successful.
Related
I made some changes to a file and committed it. (In fact there were several commits).
Then I wanted to revert to the earlier version and lose all those changes.
I did something like:
hg update -r nnn where nnn was the reversion number of the changeset I wanted to go back to.
That worked. I was happy.
Then, later, I had to push my local repository to the remote. But when I did hg push I got a message about there being two heads on this branch and one of them not being known to the remote repositiory. It suggested I merge before pushing. (I think).
I googled this and found a page that suggested I do "hg merge". I did that. Now the resultant file is back to where I started. I.e. it contains all the changes I wanted to throw away.
Where did i go wrong?
EDIT:
I have found this post Mercurial — revert back to old version and continue from there
where it says:
If later you commit, you will effectively create a new branch. Then
you might continue working only on this branch or eventually merge the
existing one into it.
That sounds like my case. Something went wrong at the merging stage it seems. Was I on the wrong branch when I did "hg merge"?
You're past this point now but if it happens again, and it's just a single file you want to revert then consider:
hg revert --rev REVISION_YOU_LIKED path/to/just/one/file.txt
That doesn't update you whole repository to a different revision, and it doesn't create any commits. It just takes a single file in your working directory and makes it look like it used to. After doing that you can just commit and you're set.
That's not the way to go if you want to undo all the changes you've made to all files, but for reverting a single file use revert and avoid multiple heads and merging entirely.
No, nothing went wrong at the merge stage – Mercurial did exactly what you asked it to...
What merge means is that you take the changes on your current branch, and the changes on the 'other' branch, and you merge them. Since your original changes were in the 'other' branch, Mercurial carefully merged them back into your current branch.
What you needed to do was to discard the 'other' branch. There are various ways of doing that. The Mercurial help pages discuss the various techniques, but there are pointers in other SO questions: see for example Discard a local branch in Mercurial before it is pushed and Remove experimental branch.
(Edit) Afterthought: the reason you got a warning about there being two heads on the branch is because having two heads is often a temporary situation, so pushing them to a remote repository is something you don't want to do accidentally. Resolutions are (i) you did mean to push them, so use --force to create two heads in the remote repository; (ii) ooops!, you meant to merge them before pushing, so do that; or (iii) ooops!, you'd abandoned the 'other' one, so get rid of it. Your case was (iii).
I recently let the IDE replace a trivial text in the entire project, and recognized that mistake only after committing other changes to Mercurial. I panicked and (knowing very little about Mercurial, now after having read the definitive guide starting to get to know it better) tried every command that seemed to make my mistake "go away". It goes without saying that this was a move I am not proud of.
Of the things I remember to have tried was hg update tip and hg rollback. Since I'm using Mercurial on my local machine only and do not pull or push from any other repository, I think these commands did not cause my main problem: There are a lot of files missing now -exactly the files I let the IDE make the wrong replacements in.
What bothers me is that I have done hg status --change REV to find all files changed in a revision, and the deleted files do not show up there.
PHPStorm has a local history, which shows which files are now missing. That (only that?) enables me to hunt down the individual files and revert to their last known revision:
hg log -l 1 path/to/foo.txt
hg revert -r <my revision> path/to/foo.txt
... but that is way too time-consuming for the hundreds of files that got changed. Please tell me there's a better way. The PHPStorm history is nice and can restore the files as well, but it will restore them to the point where they had already been erroneously changed.
Your help is greatly appreciated, and I vow to learn & appreciate Mercurial as more than just a context menu item starting today.
If you are willing to lose the changes that were committed with or since the error, you may be able to go back to the revision just before the error, and start working from there. Use hg log to find out which revision you need, and hg update --rev XX to go to that revision. If you're not sure which revision you want, update to various revisions and take a look.
Once you have updated to the correct revision, you can just continue working from there. The next time you commit, you will automatically create a new branch on which you'll be working, which will not have the error in it. If you want, you can go back to the original branch and close it.
You might even be able to get back any correct commits that happened after you committed the error up to the revision you rolled back to. On the old branch, identify the revision after the error, and do a diff between that revision and the tip of that branch. Then, see if you can apply the diff as a patch on your new branch. You will still lose any changes that were in the same commit as the error, though.
Is it
pull
update
merge
commit
push
? Or can you do the commit first?
I don't like the idea of pulling and merging without having a version of my local code backed up somewhere in case the merge explodes, but presumably you have to do the merge before you can do a push, because you can't have conflicts in the central repo. Not quite understanding this whole process yet; used to my nice simple SVN.
I recommend to always commit before pulling in changes to your working directory, unless you are 100% sure that your changes and the changes to be merged into your working directory will not conflict.
If you do an updating pull (hg pull; hg update, or shorter hg -u pull) and have any outstanding non-committed changes, any changes coming from outside will be combined with your changes. When conflicts happen, it might be difficult to decide how the merge result should look like, because you can't easily distinguish between your changes and the changes merged in.
When you did commit first, it is much easier to decide how the merge result should look like, because you can always look at both parents of the merge.
So, in effect it is:
hg commit
hg pull -u (if no merge necessary, go to 5)
hg merge
hg commit
hg push
Update: As Martin Geisler has pointed out, it is possible to get at the "original" changed version of a file using:
hg resolve --unmark the-file
hg resolve --tool internal:local the-file
or for all files at the same time:
hg resolve --unmark --all
hg resolve --tool internal:local -all
Still, I find the "commit first" system nicer. At the end, it is personal preference...
I don't know as there's a standard per se, but one of the ideas behind Mercurial is that you can commit as often as you like since it goes to your local repository. So you can commit to your heart's content as much as you like before you pull updates.
I tend not to commit very often, saving up for when I'm preparing to push, but that's me. I can see the utility of committing early and often. I do pull updates frequently as I work to cut down on merge fun.
One other thing I do is to keep a parallel clone of my working repo (cloned from the same repository as my working repo, not cloned from my working repo) so that I can check the original state of a file easily, and if need-be check in an out-of-band emergency fix or what-have-you without complicating my current change set.
Do edits
Commit
Goto 1 until satisfied
Pull
Merge & commit
Push if you want to.
Definitely commit before trying to do something complex like a merge. I don't think mercurial will allow you to merge before committing, but even if it did, what if the merge goes wrong. You have no pre-merge revision to go back to.
Commit early, commit often.
If you don't, you are missing out on a huge benefit of a DVCS.
but presumably you have to do the merge before you can do a push, because you can't have conflicts in the central repo
Wrong statement and poor understanding of distributed workflow and parallel development.
You can merge heads before push, but not have or must. Push can put any data to repo, if it needed and intended to be so
By default, push will not allow creation of new heads at the destination,
since multiple heads would make it unclear which head to use. In this
situation, it is recommended to pull and merge before pushing.
(NB: "recommended to pull and merge before" statement)
You can use commit-pull-merge, stash-pull-unstash-merge, perform fetch with modified WC and merge on the fly, don't merge heads at all or sporadically and push --force with +1 heads - there are not common rule for everybody. And any and every such workflow doesn't produce "conflicts in the central repo", but only different DAG.
Each point of divergence, which appear in case of existing your and other changeset from commmon parent in your (or even central) repo is a point of starting anonymous branches in Hg, which (technically) are absolutely legal, applicable and usual way. How they handled is defined by policy and agreement between developers, PM, QA-team and others
I, personally, prefer finish my task (in one or more amount of commits), after it pull and maybe merge, when it approved by development-policy
I am coming from CVS background.
Currently, I have 2 mercurial repositories developed parallel. hello-world-bugfix and hello-world-feature (This one is being cloned from hello-world-bugfix)
Now, I want to merge the bug fixed code from hello-world-bugfix into hello-world-feature, so that end of the day, I will get a merged file.
[BUG2 BUG2 BUG2]
START
[BUG1 BUG1 BUG1]
[FEATURE2 FEATURE2 FEATURE2]
Here is how all the things looks like before, pulling and merging. The below two files had already been committed.
Now, I perform pull from hello-world-feature, to pull changes from hello-world-bugfix.
Then, I perform update, with always merge options turned on.
Here is my merged file???
[BUG2 BUG2 BUG2]
START
[BUG1 BUG1 BUG1]
It seems that my previous committed [FEATURE2 FEATURE2 FEATURE2] being overwritten.
It seems that I shouldn't perform update step, which will not merge feature with bug, but overwrite feature away with bug. What is the next correct step I should do after pulling? (through TortoiseHg), so that I can get bug fix code, and remain feature code there?
Here is the final repository view of hello-world-feature
The "always merge" option doesn't do what you think it does.
It only merges uncommitted changes.
When you update, committed files are replaced with the new version.
To merge committed changes, ie. merge branches, you need to do an explicit merge.
So, I would select the BUG2 BUG2 BUG2 changeset in the log, then right-click on the FEATURE2 FEATURE2 FEATURE2 changeset and click Merge, and follow the instructions.
Let me expand on what the "Always merge" checkbox does.
Let's say I have two changesets in my repository, I update to the first of them, then I start modifying one of the files.
At some point I decide it would be better to have started from the other changeset instead, so I want to update to it, keeping my modifications.
If I simply do an update, with uncommitted changes, I get this dialog box when I try to update:
However, if I check the "Always merge (when possible)" checkbox, it will simply assume that I clicked on the Merge button in that dialog and not prompt me.
So the "Always merge" does not have any function at all on committed files, it won't introduce merges for you, it will only try to move your local changes along with the update.
If I do 'hg status' and see the following:
R flash/AC_OETags.js
it seems to mean that there is no file there, but there has been one at some point that has been removed.
How do I 'commit' this change so it stops showing up when I do 'hg status'?
==UPDATE==
The answer seems to be to commit the file. Actually, there are ~100 files with status R because I removed an entire directory tree. Anyone know how to commit all files in a directory tree in one go?
I don't want to do just hg commit, because there are other changes too.
The “R” means “Removed” so the next time we commit in Mercurial this file will be removed. (The history of the file will remain in the repository, so of course we can always get it back).
therefore run your hg commit command and all will be well
Thanks to hginit.com for that titbit - its my Mercurial bible
You can commit just that file:
hg commit flash/AC_OETags.js
however having "masses of other uncommitted files" is terrible process. You need to come up with a workflow that lets you commit frequently.
You can use the repository explorer from TortoiseHg to easily manage the files you want to include in a commit.
Also, removing a directory probably warrants a changeset in itself. You should get into the habit of committing more often (one concept, one commit... and it's local anyway). Furthermore, as long as you haven't pushed your changes to anyone (or anyone pulled from you) you could still use hg rebase --collapse to regroup some changesets if you think you have separated too much (this is a more advanced feature that I suggest you try on a test repository first as you could break things if you're not careful)