Re: ! [rejected] master -> master (non-fast forward)

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 18, 2007, 18:10 UTC
Message-ID: <7v7ikfwhkj.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <9e4733910711180712n6ee271fau774310e63ab08f6d@mail.gmail.com>

"Jon Smirl" <jonsmirl@gmail.com> writes:

Show 9 quoted lines

> What's causing this? I'm using stgit on the master branch.
> I'm fixing it each time on the remote server by deleting the ref to master.
>
> jonsmirl@terra:~/ds$ git push digispeaker
> To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git
>  ! [rejected]        master -> master (non-fast forward)
> error: failed to push to
> 'ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git'
> jonsmirl@terra:~/ds$

A "non-fast forward" means that you had this history earlier:

         o---o---A
        /
    ---o

pushed "A" to the remote's 'master', then built this history:

         o---o---A
        /
    ---o---o---o---o---A'

by rewinding and rebuilding, and the tip of the branch now points at A', which you tried to push to the remote.

Which often causes troubles for people who are fetching from the branch you are pushing into, and forbidden by default as a safety measure.

As long as the people who fetch from the branch knows that you will regularly rewinding the tip of the branch, there is no confusion, and you can "force" a non-fast forward update. There are two independent safety mechanisms:

 - the sending end safety can be overriden by "git push --force"
   and/or by using a refspec prefixed with a '+');

 - the receiving end safety can be overriden by the config
   variable receive.denynonfastworwards of the repository you
   are pushing into.

The latter defaults to "unsafe", but if the safety is activated in the repository, forcing from the sending side will not deactivate it. IOW, both ends need to agree to allow the unsafe behaviour.

Show 10 quoted lines

> On the server I have:
> [core]
>         repositoryformatversion = 0
>         filemode = true
>         bare = true
>         logallrefupdates = true
>
> bare was set false, I just flipped it to true. The server repo was
> originally created via a clone from kernel.org and then renamed to be
> a bare repo. Why do we need a 'bare' attribute?

There are a few things that change behaviour depending on the bareness of the repository. One example is that "git fetch" that updates to the current branch (i.e. what HEAD points at) by having it as the RHS of a refspec is accepted only for bare repositories (for non-bare repositories such a fetch would make the HEAD and the work tree go out-of-sync).