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.
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).
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html