I've got the following problem:
I have 2 named branches which are 2 completely versions of the product (e.g A and B) than at some moment I was needed to introduce changes from A to B so I started the following command:
hg merge A
after that commit and push ... and instead of 2 branches I've got 1 that was unexpected for me since I wanted just update B with changes in A. Somehow I managed to get again 2 branches and now I want to delete last commit in branch B and cant find the best way (I'd say any way) to do it.
Thanks.
Just continue commiting to the branch that you want stil alive. There is a command to explicitely kill a branch but if you don't use it, all branches are still alive in parallel. If you don't see them it's only because the tool to see them don't show them all if they are not different, but they're still present. Just continue to work with those branches and it will be fine.
Now to remove a changeset, you "can't" as in really removing it, but you can commit an exact inverse of that specific changeset. The command to do this is backout.
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).
Requirement
I'd like to abandon a line of development on the default branch, winding back to a revision from about 15 change sets back, and have default proceed from there.
My setup
This is a solo development project with one other guy testing infrequently. I push (frequently) to bitbucket for backups and sharing with the tester. Several of the changes I want to abandon are pushed to BitBucket.
Options
Any of these would be fine…
The abandoned change sets to continue to exist in the repo. It would be nice if they could live on their own branch abandoned-experiment-1, say, that I can close and ignore, but this would need them to move on to a retrospectively created branch (which seems like it would be an awesome feature?).
Some kind of merge to happen where I add a new revision to default that is the rollback to the revision I want to continue from.
The change sets to be destroyed, but I suspect there's no way to achieve that without replacing the BitBucket repo and my tester's repo, which I'm not keen on.
I'm not too sure how to evaluate which options are possible, which is best, or whether there are other, better options. I'm also not sure how to actually proceed with the repo update!
Thank you.
You do have several options (Note that I'm assuming that you are dispensing with all changes in the 15 or so revisions and not trying to keep small bits of them):
Easiest is kinda #2: You can close anonymous branches just like named branches; Tag the tip first with abandoned-development if you wish; hg update to the point you wish to continue from; and continue to code as normal. (You may need to create the new head for new development before you can close the old one. I haven't tested it yet.)
Regarding #3: Based on my cursory read, it does appear that bitbucket has a strip command. If you (both locally and on bitbucket) and your tester strip the offending changesets, you can carry on your merry way and pretend like they never existed.
Achieving #1: If you are definitely set on getting them to a named branch, you could strip them at the remote repos and then hg rebase them onto a new branch locally and then close that branch.
Personally, I try not to mess with history when I can avoid it, so I'd go with the easiest.
Mercurial now has (yet experimental) support for changeset evolution. That is you are able to abandon or rebase already pushed changesets. Internally this works by hiding obsolete changesets (i.e. practically nothing is stripped, only new replacement revisions are added to the history, that is why it works across multiple clones).
To extend #Edward's suggestions, you could also update to the last good revision, continue to commit from there and then merge in the head of the bad changesets using a null-merge:
hg up <good-revision>
... work ... commit ...
hg merge <head-of-bad-revisions>
hg revert --all -r .
hg commit -m 'null-merge of abandoned changesets'
This may be what you thought of as option 2.
I'm working with another programmer and he keeps creating multiple heads in mercurial without knowing how it's happening. I can't seem to (remotely) debug the problem so I'm stuck wondering what could cause the automatic and silent creation of a second head.
hg merge fixes the problem but I'd like to stop this.
He's on a windows machine and I'm on linux and I activated the EolExtension.
We are using a central repo but it seems uninvolved.
These are probably happening when a commit is performed from a revision that is not the tip (or the last revision of whatever branch you're working on, if using multiple named branches). This creates anonymous branches which must be merged. It's not uncommon and doesn't mean anything's necessarily broken. If these commits from further up the branch are intentional, then you'll just have to get used to merging heads. In order to avoid creating multiple heads, perform hg pull -u before committing (though you may still need to do some merging or syncing).
I'm using mercurial VCS, I've mistakenly pushed three commits and I want them to be undone, can this be achieved?
I'm pretty sure no changes were propagated to anyone from the repository I pushed to, so I'm confident that this won't break anyones code...
I've tried hg rollback but since I have pushed I cannot undo anything in the right way. Also I know about hg backout, but I'm not sure if I should use this one for what I need...
Thanks!
EDIT
This is the graph log, I forgot to mention that some commits were part of a merge, but they too need to be undone...
tip
|
a
| \
| b
| /
c
|
d
I need to return the tip to c, or d if there is no other way to prevent that because of the merge...
If it's already pushed, there are only two things that you can do now:
1) If you are able to delete the central repository and replace it by another one:
You can clone the central repository, but tell Mercurial to clone only up to changeset "c".
Then you can take this repository (which doesn't have the wrong changes) and replace the "old" central repository (the one which does have the wrong changes) with it.
Disadvantage: if someone already pulled the unwanted commits and later pushes again, they are in the repository again.
So you need to make sure that either no one pulled the mistakes, or everybody who did deletes his clone.
2) If option 1 is not possible, you can use hg backout to undo the effects of the wrong changes - not the changesets themselves.
Quote from the link:
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.
So the three wrong changesets will remain in the repository, plus another three will be added, each of them reverting the effects of one of the three wrong changesets.
If you do it like this, it doesn't matter if someone else already pulled the wrong changes...as soon as he pulls the three "backout" changesets as well, everything is okay again.
If you're positive the push is the last thing that happened to that remote repository, meaning neither you nor anyone else has pushed to it, you can login to that system and run hg rollback.
If it's a repository on a machine to which you can ssh you can run this command on your local system:
ssh you#there hg -R /path/to/the/repo rollback
As always please do be really careful with rollback. It undoes the last action on the repository without altering the working directory at all, and it's not always clear what the last action was. For example, this is datalosss:
...hack...
hg commit -m 'important work'
hg update somewhere else
hg rollback
Yikes!
We just changed over to mercurial from subversion and there is one thing that is taking up more time than expected; merging heads.
We love the fact that it keeps merges independent from the 2 commits (compared to subversion) but we end up on a regular basis merging 2 heads for unrelated changes.
Simple scenario.
Both me and Bob are up to date.
We both have ou repo up to date on default (aka main) branch and do improvement in different files.
We commit and only one will be able to push to the central server, the other one will create 2 heads. Then, pull, select 2 heads, merge (it will go easily since changes are on different files). Commit, then push.
Therefore, is there an extension that does these steps
Attempt merge
If no conflicts
Commit
else
Cancel merge
We are looking to have this run on an automated server, so +1 it this is command line and another +1 if it can do the merge without touching the working copy.
Thanks!
Update:
We ended up doing a few python scripts to manage the most common tasks (merge up & build; merge 2 heads).
Thanks for the help!
It sounds like you should be able to use hg fetch for this. It'll pull the changes from the server, merge, and then automatically commit the merge. It does prompt for merge conflicts as well. It's included with Mercurial, so just add
fetch =
to your hgrc, and you should be all set. It doesn't automatically push, but that's usually a bad idea anyway. You would typically want to run tests and resolve any merge problems before pushing your code out to everyone else.
Are the merges really taking that much time? If they're "unrelated changes" doesn't it just take a blink?
Someone already suggested fetch and someone else will probably suggest rebase, but personally I consider merging to be coding, and want it to be manual. It takes almost no time and it's an opportunity to give a good message like "Pulling in Jane's work half-way through my FooBar work" (instead of the useless commit messages fetch provides).