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://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen ! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen'
Bruce KorbRe: failed to push
Bruce Korb wrote:
> 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://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen > ! [rejected] master -> master (non-fast forward) > error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/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.
Chris PackhamRe: failed to push
Hi,
On Mon, Mar 1, 2010 at 1:23 PM, Bruce Korb <bruce.korb@gmail.com> wrote:
> Bruce Korb wrote: >> 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://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen >> ! [rejected] master -> master (non-fast forward) >> error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/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.
> > 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.
Re: failed to push
Hi,
Thank you-all for your replies.
Chris Packham wrote:
>>> To ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen >>> ! [rejected] master -> master (non-fast forward) >>> error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen'
CF:
> 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.
> 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.
> 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.
> 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.
> 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.
I will be trying this procedure momentarily. Meanwhile, since I am the only person on the planet authorized to commit to the public repo:
> - or - > > git push -f
This fails with the same "non-fast forward" rejection message. :(
Re: SUCCESS -- failed to push
Bruce Korb wrote:
>> 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. > > 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
Erik Faye-LundRe: failed to push
On Mon, Mar 1, 2010 at 11:00 PM, Bruce Korb <bkorb@gnu.org> wrote:
> Hi, > > Thank you-all for your replies. > > Chris Packham wrote: >>>> To ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen >>>> ! [rejected] master -> master (non-fast forward) >>>> error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen' > > CF: >> 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.
>> 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. >
"git help commit" gives a warning about this when documenting --amend, and links to the full description in the rebase-documentation.
>> 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.
> 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.
>> - 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"
-- Erik "kusma" Faye-Lund
Jakub NarebskiRe: failed to push
Bruce Korb <bkorb@gnu.org> writes:
> Chris Packham wrote: > >>> To ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen > >>> ! [rejected] master -> master (non-fast forward) > >>> error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen' > > CF: > > 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.
> > 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.
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.
> > 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.
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...
> > 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. > > I will be trying this procedure momentarily. Meanwhile, since I am > the only person on the planet authorized to commit to the public repo: > > > - 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.
-- Jakub Narebski Poland ShadeHawk on #git
Chris PackhamRe: failed to push
On Tue, Mar 2, 2010 at 11:09 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> 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
>Bruce Korb <bkorb@gnu.org> writes: >> 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).
[gitbook PATCH] 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(-)
diff --git a/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown b/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown index b37245d..8b876f2 100644 --- a/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown +++ b/text/21_Redoing_Git_Reset_and_Revert/0_ Redoing_Git_Reset_and_Revert.markdown @@ -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 #### diff --git a/text/25_Changing_Your_History/0_Changing_History.markdown b/text/25_Changing_Your_History/0_Changing_History.markdown index b569f46..160c838 100644 --- a/text/25_Changing_Your_History/0_Changing_History.markdown +++ b/text/25_Changing_Your_History/0_Changing_History.markdown @@ -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.
-- 1.7.0.1
Jacob HelwigRe: failed to push
On Mar 1, 2010, at 13:15, Bruce Korb <bkorb@gnu.org> wrote:
> 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://bkorb@autogen.git.sourceforge.net/gitroot/autogen/autogen > ! [rejected] master -> master (non-fast forward) > error: failed to push some refs to 'ssh://bkorb@autogen.git.sourceforge.net > /gitroot/autogen/autogen' > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > 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.