failed to push
Hi,
This message has no meaning at all. I know it failed to push. I can tell from the comment "[rejected]". It would be nice to know *WHY* it was rejected so I can fix the problem. How do I determine the cause, please? Thank you!! Regards, Bruce
$ git push To ssh://[email protected]/gitroot/autogen/autogen ! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'ssh://[email protected]/gitroot/autogen/autogen'
Quoted 7 lines · Bruce Korb
Hi,
This message has no meaning at all. I know it failed to push. I can tell from the comment "[rejected]". It would be nice to know *WHY* it was rejected so I can fix the problem. How do I determine the cause, please? Thank you!! Regards, Bruce
Quoted 9 lines
$ git push To ssh://[email protected]/gitroot/autogen/autogen ! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'ssh://[email protected] /gitroot/autogen/autogen' -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
It tells you right there at the end of the rejected line. The push would have resulted in a non-fast-forward update of the branch.
To "fix" this, you need the current commit pointed to by the branch as one of the ancestors of the commits you're trying to push.
Quoted 7 lines · Bruce Korb
Hi,
This message has no meaning at all. I know it failed to push. I can tell from the comment "[rejected]". It would be nice to know *WHY* it was rejected so I can fix the problem. How do I determine the cause, please? Thank you!! Regards, Bruce
Quoted 5 lines
$ git push To ssh://[email protected]/gitroot/autogen/autogen ! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'ssh://[email protected]/gitroot/autogen/autogen'
A little follow up context:
I used the "git gui citool". I saw a button to allow an amendment to a previous checkin. That seemed most appropriate, so I did that. I had previously pushed the commit to the sourceforge repository, so my guess was that pushing would amend the checkin at sourceforge, too. Nope. Won't let me push. Won't tell me why, either. Now what? Thanks.
Hi,
Quoted 8 lines · Bruce Korb
Quoted 7 lines · Bruce Korb
Hi,
This message has no meaning at all. I know it failed to push. I can tell from the comment "[rejected]". It would be nice to know *WHY* it was rejected so I can fix the problem. How do I determine the cause, please? Thank you!! Regards, Bruce
Quoted 5 lines
Quoted 5 lines
$ git push To ssh://[email protected]/gitroot/autogen/autogen ! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'ssh://[email protected]/gitroot/autogen/autogen'
This basically means that the push you have attempted is not a simple fast forward. This basically means that the commit your work is based on is not present in the remote or that there have been other pushes to the remote and you need to pull them into your repository to handle any merging.
Quoted 9 lines
A little follow up context:
I used the "git gui citool". I saw a button to allow an amendment to a previous checkin. That seemed most appropriate, so I did that. I had previously pushed the commit to the sourceforge repository, so my guess was that pushing would amend the checkin at sourceforge, too. Nope. Won't let me push. Won't tell me why, either. Now what? Thanks. --
OK that kind of sheds some light. I take it you've just switch from a centralized VCS?
In a DVCS like git all commits happen locally, the only time commits are sent to the remote repo are when you've pushed so 'git commit --amend' or 'git gui' with the amend box ticked only makes the change locally it won't implicitly figure out that a commit has been pushed out into the ether. One rule of thumb with git (I think it applies to most DVCSes) is not to amend a commit that has been pushed for this very reason. Strictly speaking all commits are immutable, when you amend a commit you actually create a whole new commit and your old one is marked for garbage collection (if nothing else is based off it).
In terms of recovering from your present situation I'd try the following (Disclaimer: maybe you shouldn't try these based solely on my advice. I'm still learning too)
git pull
<resolve merge issue, 'git mergetool' is your friend> git push
I think this will basically sort things out but you may need to hand
hold a few things through a merge depending on how different the 2 commits are.
- or -
git push -f
If you're the only one using that repository its probably fine but
this could cause problems for others if they've cloned the repo before your amended commit.
Hi,
Thank you-all for your replies.
Quoted 3 lines · Chris Packham
Quoted 3 lines
Quoted 3 lines
To ssh://[email protected]/gitroot/autogen/autogen
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'ssh://[email protected]/gitroot/autogen/autogen'
CF:
Quoted 2 lines
It tells you right there at the end of the rejected line. The push would have resulted in a non-fast-forward update of the branch.
"non-fast forward" is not very helpful either.
Quoted 5 lines
This basically means that the push you have attempted is not a simple fast forward. This basically means that the commit your work is based on is not present in the remote or that there have been other pushes to the remote and you need to pull them into your repository to handle any merging.
Since the sequence was:
git commit
git push
<more editing>
git commit --amend
git push
the neophyte (me) is not going to know that this produces an un-pulled delta.
Quoted 2 lines
OK that kind of sheds some light. I take it you've just switch from a centralized VCS?
"just switched"? No, I've been using BitKeeper for four years and just recently converted my open source stuff to GIT. GIT is harder to work with.
Quoted 7 lines
In a DVCS like git all commits happen locally, the only time commits are sent to the remote repo are when you've pushed so 'git commit --amend' or 'git gui' with the amend box ticked only makes the change locally it won't implicitly figure out that a commit has been pushed out into the ether. One rule of thumb with git (I think it applies to most DVCSes) is not to amend a commit that has been pushed for this very reason.
Then please be kind enough to put a *CAUTION* button next to the amend button and have it bring up something that gives you a little warning. GIT *could* have been written in a way that causes the remote repo to become synced with my local repo, but apparently it was not and there was not adequate warning.
Quoted 8 lines
Strictly speaking all commits are immutable, when you
amend a commit you actually create a whole new commit and your old one is marked for garbage collection (if nothing else is based off it).In terms of recovering from your present situation I'd try the following (Disclaimer: maybe you shouldn't try these based solely on my advice. I'm still learning too)
Quoted 7 lines
git pull
<resolve merge issue, 'git mergetool' is your friend> git pushI think this will basically sort things out but you may need to hand
hold a few things through a merge depending on how different the 2 commits are.
I will be trying this procedure momentarily. Meanwhile, since I am the only person on the planet authorized to commit to the public repo:
Quoted 3 lines
- or -
git push -f
This fails with the same "non-fast forward" rejection message. :(
Re: SUCCESS -- failed to push
Quoted 8 lines · Bruce Korb
Quoted 8 lines
In terms of recovering from your present situation I'd try the following (Disclaimer: maybe you shouldn't try these based solely on my advice. I'm still learning too)
git pull
<resolve merge issue, 'git mergetool' is your friend> git push
Quoted 5 lines
Quoted 3 lines
I think this will basically sort things out but you may need to hand
hold a few things through a merge depending on how different the 2 commits are.I will be trying this procedure momentarily.
There were no resolution issues. "git pull ; git push" was sufficient. Thank you all for your help! Regards, Bruce
Quoted 9 lines · Bruce Korb
Hi,
Thank you-all for your replies.
Quoted 3 lines · Chris Packham
Quoted 3 lines
Quoted 3 lines
To ssh://[email protected]/gitroot/autogen/autogen
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'ssh://[email protected]/gitroot/autogen/autogen'
Quoted 6 lines
CF:
Quoted 2 lines
It tells you right there at the end of the rejected line. The push would have resulted in a non-fast-forward update of the branch.
"non-fast forward" is not very helpful either.
How so? "git help glossary" gives you a description of what a fast-forward is. In my installed copy, it's spelled without a dash, though. But that's a minor nit, I still found it easily.
Quoted 13 lines
Quoted 5 lines
This basically means that the push you have attempted is not a simple fast forward. This basically means that the commit your work is based on is not present in the remote or that there have been other pushes to the remote and you need to pull them into your repository to handle any merging.
Since the sequence was:
git commit
git push
<more editing>
git commit --amend
git push
Quoted 3 lines
the neophyte (me) is not going to know that this produces an un-pulled delta.
"git help commit" gives a warning about this when documenting --amend, and links to the full description in the rebase-documentation.
Quoted 11 lines
Quoted 7 lines
In a DVCS like git all commits happen locally, the only time commits are sent to the remote repo are when you've pushed so 'git commit --amend' or 'git gui' with the amend box ticked only makes the change locally it won't implicitly figure out that a commit has been pushed out into the ether. One rule of thumb with git (I think it applies to most DVCSes) is not to amend a commit that has been pushed for this very reason.
Then please be kind enough to put a *CAUTION* button next to the amend button and have it bring up something that gives you a little warning.
That sounds to me like a good idea. Care enough to make a patch.
Quoted 4 lines
GIT *could* have been written in a way that
causes the remote repo to become synced with my local repo, but apparently it was not and there was not adequate warning.
That would have caused problems for anyone who cloned. But yes, git-gui might benefit from a warning here.
Quoted 5 lines
Quoted 3 lines
- or -
git push -f
This fails with the same "non-fast forward" rejection message. :(
I've seen this on sourceforge as well, it seems they have some extra checks (hooks?) to disallow pushing rebased branches. The best thing would be not to rewrite it. But if you INSIST, what worked for me was to delete the branch and then re-pushing it. Something like this "git push remote-name :branch-name && git push remote-name branch-name"
Signature · 1 line
Erik "kusma" Faye-Lund
Quoted 10 lines · Bruce Korb
Quoted 3 lines · Chris Packham
Quoted 3 lines
Quoted 3 lines
To ssh://[email protected]/gitroot/autogen/autogen
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'ssh://[email protected]/gitroot/autogen/autogen'CF:
Quoted 2 lines
It tells you right there at the end of the rejected line. The push would have resulted in a non-fast-forward update of the branch.
"non-fast forward" is not very helpful either.
It is part of git jargon, and can be found in gitglossary.
Quoted 13 lines
Quoted 5 lines
This basically means that the push you have attempted is not a simple fast forward. This basically means that the commit your work is based on is not present in the remote or that there have been other pushes to the remote and you need to pull them into your repository to handle any merging.
Since the sequence was:
git commit
git push
<more editing>
git commit --amend
git push
Quoted 2 lines
the neophyte (me) is not going to know that this produces an un-pulled delta.
Well, all of us old gitters know: 1) that you should not change published (pushed) history, 2) that commits are immutable, and 3) that amending a commit generates new commit with correction and therefore changes history.
It is true that git documentation ("Git User's Manual", "Git Community Book", "Pro Git") can be lacking... unfortunately by the time somebody is knowledgeable enough to write git documentaions, he/she is usally used to git way of doing things, and the documentation might not be newbie-friendly.
Quoted 8 lines
Quoted 7 lines
In a DVCS like git all commits happen locally, the only time commits are sent to the remote repo are when you've pushed so 'git commit --amend' or 'git gui' with the amend box ticked only makes the change locally it won't implicitly figure out that a commit has been pushed out into the ether. One rule of thumb with git (I think it applies to most DVCSes) is not to amend a commit that has been pushed for this very reason.
Quoted 5 lines
Then please be kind enough to put a *CAUTION* button next to the amend button and have it bring up something that gives you a little warning. GIT *could* have been written in a way that causes the remote repo to become synced with my local repo, but apparently it was not and there was not adequate warning.
What git-gui (and other git interaces) could do is to check if there is indicator that the part of history you want to change (via amending a commit, or via [interactive] rebase) is published. On the other hand you probably would not want for git to access network to check it before history-rewriting commands...
Quoted 16 lines
Quoted 8 lines
Strictly speaking all commits are immutable, when you
amend a commit you actually create a whole new commit and your old one is marked for garbage collection (if nothing else is based off it).In terms of recovering from your present situation I'd try the following (Disclaimer: maybe you shouldn't try these based solely on my advice. I'm still learning too)
Quoted 7 lines
git pull
<resolve merge issue, 'git mergetool' is your friend> git pushI think this will basically sort things out but you may need to hand
hold a few things through a merge depending on how different the 2 commits are.
Quoted 8 lines
I will be trying this procedure momentarily. Meanwhile, since I am the only person on the planet authorized to commit to the public repo:
Quoted 3 lines
- or -
git push -f
This fails with the same "non-fast forward" rejection message. :(
Whether you are able to force pushing non fast-forward changes depends on configuration on remote side (receive.denyNonFastForwards), and on the update / pre-receive hooks which can also forbid forcing non fasf-forward changes.
Signature · 3 lines
Jakub Narebski Poland ShadeHawk on #git
Quoted 10 lines · Jakub Narebski
Well, all of us old gitters know: 1) that you should not change published (pushed) history, 2) that commits are immutable, and 3) that amending a commit generates new commit with correction and therefore changes history.
It is true that git documentation ("Git User's Manual", "Git Community Book", "Pro Git") can be lacking... unfortunately by the time somebody is knowledgeable enough to write git documentaions, he/she is usally used to git way of doing things, and the documentation might not be newbie-friendly.
I thought I smelt an easy documentation patch but the current help for git commit --amend seems to cover it
"You should understand the implications of rewriting history if you amend a commit that has already been published"
These sections [1],[2] of the git community book could probably do with a note on the consequences or re-writing history. I'll see if I can figure out how to submit a change.
[1] http://book.git-scm.com/4_undoing_in_git_-_reset,_checkout_and_revert.html
[2] http://book.git-scm.com/5_modifying_your_history.html
Quoted 6 lines
Quoted 5 lines · Bruce Korb
Then please be kind enough to put a *CAUTION* button next to the amend button and have it bring up something that gives you a little warning. GIT *could* have been written in a way that causes the remote repo to become synced with my local repo, but apparently it was not and there was not adequate warning.
Shouldn't be too hard to repeat the warning from git help commit. Just not sure of what the least intrusive way to do it is (plus my tcl-fu is weak).
PATCH 1/1 add notes on re-writing history
Add a note on the consequences of re-writing a repositories history in "Undoing in Git - Reset, Checkout and Revert/Fixing a mistake by modifying a commit" and "Modifying your History".
---
I didn't sucessfully get the ruby gems installed on openSUSE 11.2 (problems installing ultraviolet) so if someone who does have a working environment could have a look and maybe do a bit of polishing that would be helpful.
.../0_ Redoing_Git_Reset_and_Revert.markdown | 6 +++++- .../0_Changing_History.markdown | 20 ++++++++++++++++++-- 2 files changed, 23 insertions(+), 3 deletions(-)
text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown +5 -1
@@ -43,7 +43,11 @@ fundamentally different ways to fix the problem: never do this if you have already made the history public; git does not normally expect the "history" of a project to change, and cannot correctly perform repeated merges from - a branch that has had its history changed. + a branch that has had its history changed. If you do re-write + a repositories history anyone else who has cloned the + repository will need manually correct the problem on their + clone see the "RECOVERING FROM UPSTREAM REBASE" section + in linkgit:git-rebase[1]. #### Fixing a mistake with a new commit ####
text/25_Changing_Your_History/0_Changing_History.markdown +18 -2
@@ -1,6 +1,22 @@ ## Modifying your History ## -Interactive rebasing is a good way to modify individual commits. +There are several ways to re-write the history of a repository. All of +these can cause problems for commits that have already been pushed to a +remote repository. If you do re-write a repositories history anyone else +who has cloned the repository will need manually correct the problem on +their clone see the "RECOVERING FROM UPSTREAM REBASE" section in +linkgit:git-rebase[1]. -linkgit:git-filter-branch[1] is a good way to edit commits en masse. +The simplest method is to use "git commit --amend" to modify the last commit. +This is useful to correct a commit message, or make a simple update to a +commit before pushing. + +Interactive rebasing is a good way to modify multiple commits. Commits can +be combined by squashing, changed by editing or removed entirely. + +linkgit:git-filter-branch[1] is a good way to edit commits en masse. This is +useful where a whole component needs to be removed from a project. For +example removing a subsystem which is licenced under an incompatible +opensource licence. Or it can be used to alter the commit authorship without +changing the code.
Signature · 1 line
1.7.0.1