I'm fairly new to Mercurial so I'm hoping someone can help me as I'm currently close to tears ;)
So I've been working locally and committing to my local repository. I wanted to push my changes to the server so I first pulled the latest changes. All ok so far.
I then tried to do a push but got the following error:
[Error: abort: push creates new remote head 80394c55f2dc!]
new remote head 80394c55f2dc
[Error: (did you forget to merge? use push -f to force)]
I then read that a pull doesn't merge the changes into my local repository.
I loaded up Workbench so I can now see my changes and the other dev's changes that have been pulled. I then did a merge on the other dev's most recent revision.
I now have two rev 112 one with a description of Merge and 112+ which says * Working Directory *
I hope I've explained this properly and I can provide screen shots if required but I'm slightly stumped.
I just need to get all changes merged and pushed.
Here's a blog post that does a decent job of explaining what you need to do. The fifth image in the post matches your situation, based on your description. In addition to revision 112, you probably have another head at another revision. You will have to click on that head and then select Merge with Local from the context menu. TortoiseHg will then guide you through the process of merging these two heads. If you do not have to intervene at all to resolve any conflicts, you will end up with a dialog with a default commit message (Merge) for the new changeset that represents a merge of the two heads (one of which came from your work and the other that came in when you pulled).
The Mercurial wiki has a nice page that should help you get comfortable working with Mercurial. I am sure you will do just fine :)
Related
I have a project with a single branch, default. I have been iterating on this single named branch for some time now and I have been using tags to mark version number milestones.
The project's source code changed quite a bit between tags 1.0.7 and 1.1.0 (current). However, there are some users on 1.0.7 that need a bug fix. So I checked out the source, updated to tag 1.0.7, implemented a fix and committed. That was tagged 1.0.8, and will probably be the last commit on the 1.0.x line.
I now have two heads on the default branch. I expected that. But when I tried to push to our BitBucket account, I received a warning from hg: "push creates new remote head". Reading up on this message, I get a lot of answers explaining why the message is there and for most people the answer is just to merge. However, I don't think I want that in this case. The two branches aren't compatible.
It looks like I can just use the -f option to force push the new head to the remote repository, however this seems to be discouraged both by hg help and various posts on the web without much explanation as to why. So what is the downside to doing this? It seems as though I can still update to whatever tags/revisions I want to continue working on. If I push that head to the BitBucket account, will I be shooting myself in the foot in some way?
Having multiple heads is perfectly fine.
If there are several heads and there's little indication as to their purpose, it may be difficult for others to see where they should continue and what is the head which contains the newest developments, e.g. which gains new features.
However by using the tags on the branch with clear versioning like you do, that problem doesn't exist either.
There's one small catch though: Mercurial will, upon clone, update to the newest commit in the default branch - e.g. the head which received the last commit. If that's the 1.0.x head of yours, that might be unfortunate. However you can fix this, by attaching the special '#' bookmark to the mainline or development head. Mercurial will always update to the head which bears that bookmark, if it is present - irrespective which head has the newest commit.
I have fork-ed a project on an organisation I'm part of. I'm trying to get the fork updated as there were commits (see below) just by using the web interface.
I've searched the net but I did not find anything relevant.
How can I do that?
Thanks
As i've never played with someone's branch before, my question sounds stupid but bear in mind : This was my first time.
Please find the way to update the branch you've forked , when that person who own the branch, committed changes and you want your fork to be the same as his branch. All done by Github's web interface
Go to the pull request tab
Click on the button New pull request
Create a pull request
Commit (as you are asking for his changes willingly, you are the one committing :))
This question pertains to my workflow using github. My colleague sent me a pull request and kept advancing the branch he was working in with new commits? I want to pull the commits related to the pull request, but the pull request now has the commits too. I searched for solutions and kept being led to the "rebase" command. Regrettably, that command is too complicated for me, plus I use tortoiseSVN as my interface to github. I had some solutions using revert, but they were all un-elegant and there had to be something easy. Also the last time I tried a revert, I had some conflicts with commits that no longer existed because of the revert.
My colleague got a response from a github "ask a human". I am reporting the solution here to help other users.
Navigate to the branch with the work to be pulled.
Navigate to the commit history for the branch and identify the point in that history that you want to pull into the master.
Click on the button on the right marked "<>" == "Browse the repository at this point in the history".
Click on the branch pull down menu and create a new branch. This will create a new branch at that point in the history that you want to pull into the master.
Create and execute a pull request to merge that branch into the master.
Too easy. I don't understand how I didn't run across an example of this workflow. I hope I save someone else the time and headaches that I spent.
I'm trying to figure out how to fix a merge problem me and my team are facing. I'm working on this project at school, and my team has made a lot of progress, but one of the team members who didn't know what he was doing force merges his code into the master branch. His branch is like 2 days old and we've already implemented a lot of new functionality since time, his branch is probably 20 or so commits away from head. I've tried rolling back to a stable master branch but his branch is intermingled with the stable so I can't seem to retrieve the stable back. Any suggestions? we are fairly new to git, but that person had no idea what was going on and just force merged his code without resolving the commits.
Go and sit on his computer.
Type git reflog, it will show you the full commit history (as well as other things). Find out the last good commit id , check it out git checkout SHA-1. create branch at this point and commit it back again. Once you are on the right commit your repository will "get back" to the last good place.
Another option is to perform a git bisect and to find out what is the bad commit.
Click here for blog about reflog
Click here for blog about bisect
Good luck.
I am working with the GitHub GUI on Windows.
I did some work on my project which was successfully committed about a month ago going forward. Unfortunately other person who also works on this project recently committed the files I changed without realizing that he removed a huge portion of my work.
Now my question would be: is there an easy way of restoring my commits. This is not one commit. For the past month I made several very important commits to the project which got killed by the other party error.
I really don't want to go thru each file individually and re-aaply the changes manually, especially since I already got paid for that work.
How can I get my commits back?
IF you don't see your commit anymore in the history of the repo, that would mean the other developer has done a forced push (git push --force).
In that case, use git reflog (as in this answer) to find your commits back.
If yo do see your commits, then you could revert (git revert) the commits introduced by the other developers in order to cancel them, which should leave your branch in a state reflecting your work.
In both cases, this is a communication issue: you need to coordinate with the other developer in order for both of you to agree on a state from which to move forward.