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