Hi, Thank you-all for your replies. 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. > 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. :( -- 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