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

[Junio C Hamano <gitster@pobox.com>]

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

> 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.

> 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).