Bruce Korb <bkorb@xxxxxxx> writes:
> Chris Packham wrote:
> >>> To ssh://bkorb@xxxxxxxxxxxxxxxxxxxxxxxxxxx/gitroot/autogen/autogen
> >>> ! [rejected] master -> master (non-fast forward)
> >>> error: failed to push some refs to 'ssh://bkorb@xxxxxxxxxxxxxxxxxxxxxxxxxxx/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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html