failed to push

failed to push

[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

$ 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'

Re: failed to push

[Bruce Korb]

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.

Re: failed to push

[Jacob Helwig]

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.

Re: failed to push

[Chris Packham]

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

[Bruce Korb]

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]

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

Re: failed to push

[Erik Faye-Lund]

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

Re: failed to push

[Jakub Narebski]

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

Re: failed to push

[Chris Packham]

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

[Chris Packham]

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