Re: failed to push
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Mar 2, 2010, 19:09 UTC
- Message-ID
- <m3tysylexh.fsf@localhost.localdomain>
- In-Reply-To
- <4B8C38E5.7090305@gnu.org>
Bruce Korb <bkorb@gnu.org> writes:
Show 10 quoted lines
> 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.
Show 15 quoted 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.
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.
Show 13 quoted 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.
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...
Show 24 quoted 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) > > > > 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