On Mon, Mar 1, 2010 at 11:00 PM, Bruce Korb <bkorb@xxxxxxx> wrote: > 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. > 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 -- 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