Re: Updated tags on repo are not updated when pull

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 3, 2012, 23:39 UTC
Message-ID: <7vfwckbd1r.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAJsNXT=mQgt++g-Tz=kfDjC+PC7wJhc77f6zu7vg8GSnJfDq3w@mail.gmail.com>

PJ Weisberg <pj@irregularexpressions.net> writes:

Show 9 quoted lines

> Basically it's a branch that no one updates
> except the build server under specific circumstances.  You could
> enforce that with hooks, but I think the biggest problem is the word
> "branch".  People (and UIs) have ideas of what a branch is and what
> it's used for, which don't *quite* match the intended use.
>
> I wonder if the Git developers have any ideas on the best way to
> maintain a pointer to the latest successful automated build, and other
> such things?

Such things, if they are not branches nor tags, can be placed under different naming hierarchy, e.g. refs/built, without interfering the normal semantics of "branches" (people expect to be able to check them out, build on them and push them back to advance their tips) or "tags" (people expect them to anchored at known points without floating). Any semantics the project wants to assign to them by social convention, and Git does not care. If the project participants are expected to always fetch them to keep them up to date in their local namespace, the project can tell them to place an extra entry for remote.origin.fetch in their repository config

	[remote "origin"]
        	fetch = +refs/built/*:refs/built/*

in the same document they tell them where and how to clone the project history from.

I would however use the usual branch perhaps with a well-known prefix if I were doing this. You would want to forbid updates of them from random people at the central site with a pre-receive hook anyway; using a different hierarchy only to avoid the word "branch" is not worth the extra complexity.