I have a coworker who is working on a branch called GL104. He made two commits and pushed those to the repository. The newest commit is faed3fd7 on the repos. He then realized he wanted to change his commit message, so he pulled it up in History, right-clicked on the newest commit and selected Modify->Reword. He changed his text and this gave him a new commit ID. He did not do a "Push Commit" or push of any kind to the server. His "status" for the project then showed him being ahead by 2 commits. I suggested he push his local branch up to the repos but it was rejected for non-fast-forward. After that his status showed him being ahead by 1 commit, behind by 1 commit. I don't understand why this is.
Anyway, I'm trying to find this on the net as I type but not finding anything yet. So what is the proper procedure here? I'm guessing he has to push his reworded commit. I'm not sure.
We are using Eclipse Mars.1
Once you push a commit, you normally cannot change the commit message. That is because behind the scenes, when you select "Reword" a new commit is created with the same parent as the old commit. When you have two commits with the same parent, a merge is required; that is why it is not letting you push the new commit.
Now, if nobody else has done a pull on the misworded commit, you can do a force push (git push -f) which will get rid of that commit and replace it with the correct one. But if anyone else has already pulled that misworded commit to their local repo, the force push will simply delay the merging from happening (i.e. when that other person does the next pull).
So, long story short, your coworker is probably best off just leaving the commit as is.
Related
I guys, Id like to know some tips about git,
I've worked with collaborators in the same repository and Id like to know if when someone makes the code's push, the code that is already there will be changed adding only the changes and when the other persor make the other git-push the code will be the union of both pushes, or the code will be replaced by the last one pushed from the last person who made the git-push.
The second person making a push won't be able to, unless he/she forces the push (git push --force), assuming they are both pushing from and to the same branch.
The best practice would be for that second person to do first:
git pull --rebase
That will replay unpushed commit on top of the update branch (with the commits from the first person). Possible merge conflicts will be resolved locally, in the second person's local Git repository.
Then a simple git push will add the new commits on top of the existing ones.
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.
So, I'm new to Mercurial, and on my first try I screwed up.
Before pushing my data, I tried to merge with one branch (which I think was an old branch)
Instead of pushing it properly to change from "draft" to "public" I manually changed it from Tortoise by using the change phase from "draft" to "public"
I thought it meant that it would be placed in the repository, but when I went to the actual repository (on Bit Bucket) I couldn't find it.
So what happened, is I think I never made a push.
This is causing me an issue to make new changes, because when I tried committing other files, merging it with other branches and pushing it to the repository, i get the error:
searching for changes
remote has heads on branch 'branch one' that are not known locally: 62bf86f93d4f
abort: push creates new remote head 7edef5d2e2e5 on branch 'branch one'!
hint: pull and merge or see "hg help push" for details about pushing new heads
[command returned code 255 Thu May 27 14:43:44 2015]
So I think the solution would be to merge with the original draft (which is now public)
Thus my question: Is it possible to still merge and push a revision that was already deemed "public", even if I can't find it in the repository on bitbucket?
The phase of your commit (public vs. draft vs. secret) has no relevance for whether the commit can be merged. The difference between draft and public only affects whether the history involving the commit can be altered (e.g. via hg commit --amend or hg rebase). Public revisions are considered immutable, draft revisions can still be altered.
You can still merge and push. In theory, if you are positive that you didn't push the commit, you can also safely change the phase back to draft. However, that would be pointless [1], because pushing the merge will immediately make it public again [2].
[1] It can be useful if you use hg pull --rebase, but if you don't know what that does, you probably shouldn't use it.
[2] Unless you push to a non-publishing repository, but that's unlikely unless your group is using the evolve extension. If you don't know what a non-publishing repository or the evolve extension is, you don't need to know.
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 may have screwed up, but there a way to get a code review going on GitHub after I did the below workflow?
I cloned a remote repository, branched the master and made my changes. I committed the changes, merged my branch into master, then ran a sync on GitHub and the changes are there now.
I'd now like to initiate a post-checkin review, but didn't fork the repository and so can't initiate a pull request, which as I understand it now is the common way to get reviews going in github. What should my next steps be?
Next time you should just push your changes from your branch to the remote repository, then submit a "pull request" for the branch back into master where the code can be reviewed prior to merging.
When you push changes to your branch, to compare your changes, go to that branch and look for this near the top in the code tab:
This is some good reading as well about how/when to use forking & pull requests: https://help.github.com/articles/using-pull-requests
EDIT:
And since you did say this is after the fact, the other thing you can do is go to the master branch->commits section, and click on the commit where you merged your branch in. That page allows you to make comments and view the changed files, so you can still review your code before you actually push it to your server. However, you should still do the other way next time.
To clarify...you can branch locally and then change, commit etc, and then push that branch to GitHub, then fire off a pull request?
Yes, and since August 14th 2018, you don't even need to switch to the Code tab:
When you push branches while using the “Pull requests” tab, GitHub will now display the dynamic “Compare and pull request” widget—so you can quickly create a pull request without having to switch back to the “Code” tab.
Learn more about pull requests in our documentation.