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 -- 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