Re: [RFC] Hidden refs

[Jeff King <peff@peff.net>]

On Wed, Oct 13, 2010 at 11:22:11AM -0400, Marc Branchaud wrote:

> We want to have our build system record, in our repo, which commits
> correspond to which builds.
> 
> Nominally, this is a job for tags.  But we don't want to have to look at
> these tags all the time.  We particularly just want to tag the repo when we
> make an actual release -- tags are a Big Deal for us.
> 
> Notes are an option, though they feel a bit heavy for this application.  And
> although we can store the build notes in their own refspace, it would (I
> believe) be a little clunky to make commands like checkout and log work with
> the commits that were noted by the build system.

Keep in mind that notes and tags are basically inverses as far as
efficient lookup goes. If you want to map a build name or number to a
commit, you would use a ref which points to a commit. But if you want to
map a commit sha1 to a build number, you would use notes.

> It struck me that it would be neat to have hidden refs in the refs/
> directory.  I experimented a bit with a "refs/.builds" directory:
> 
> * "git update-ref refs/.builds/One" fails with "Cannot lock the
>   ref 'refs/.builds/One'."  So I created a ref the regular way
>   (refs/blah/One) and copied the "One" file into refs/.builds/.

Yeah, I believe "." at the front of a directory component is explicitly
forbidden by check_ref_format. I don't recall whether there was a
specific rationale, or whether it was simply a can of worms we didn't
want to explore.

...

Look like it blames to 03feddd (git-check-ref-format: reject funny ref
names., 2005-10-13).  This looks like the relevant thread:

  http://article.gmane.org/gmane.comp.version-control.git/9874

but I didn't read through it carefully.

-Peff