Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > +on the remote side. Whether this is allowed depends on where in > +`refs/*` the <dst> reference lives as described in detail below. Any > +such update does *not* attempt to merge <src> into <dst>. See EXAMPLES > +below for details. > ++ > +The `refs/heads/*` namespace will only accept commit objects, and only > +if they can be fast-forwarded. > ++ > +The `refs/tags/*` namespace will accept any kind of object (as > +commits, trees and blobs can be tagged), and any changes to them will > +be rejected. > ++ > +It's possible to push any type of object to any namespace outside of > +`refs/{tags,heads}/*`. In the case of tags and commits, these will be > +treated as if they were the commits inside `refs/heads/*` for the > +purposes of whether the update is allowed. > ++ > +I.e. a fast-forward of commits and tags outside `refs/{tags,heads}/*` > +is allowed, even in cases where what's being fast-forwarded is not a > +commit, but a tag object which happens to point to a new commit which > +is a fast-forward of the commit the last tag (or commit) it's > +replacing. Replacing a tag with an entirely different tag is also > +allowed, if it points to the same commit, as well as pushing a peeled > +tag, i.e. pushing the commit that existing tag object points to, or a > +new tag object which an existing commit points to. > ++ > +Tree and blob objects outside of `refs/{tags,heads}/*` will be treated > +the same way as if they were inside `refs/tags/*`, any modification of > +them will be rejected. > ++ > +All of the rules described above about what's not allowed as an update > +can be overridden by adding an the optional leading `+` to a refspec > +(or using `--force` command line option). The only exception to this > +is that no amount of forcing will make the `refs/heads/*` namespace > +accept a non-commit object. This, while some may find it overly long, is quite clear, compared to the current text and to the previous rounds of this patch, and I found it very much readable.