Linus,
not that there is any "de facto" or any standard there, but
the name .git/refs/snap/ you lifted from the vicinity thing is
not something Cogito folks have. My understanding is of their
concensus is that .git/refs have single level subdirectories
like 'heads' and 'tags', and there will be little 41-byte text
files that look like .git/HEAD. So you probably would want to
either (1) readdir in .git/refs (to future proof) or (2) drop
refs/snap from the vicinity list for now (to not give special
treatment to JIT, which I myself do not mind ;-)). Also if you
go route (2) drop "refs" itself as well.
On Sun, 1 May 2005, Junio C Hamano wrote:
Linus,
not that there is any "de facto" or any standard there, but
the name .git/refs/snap/ you lifted from the vicinity thing is
not something Cogito folks have. My understanding is of their
concensus is that .git/refs have single level subdirectories
like 'heads' and 'tags', and there will be little 41-byte text
files that look like .git/HEAD.
I was intending this to be a more general concensus (and you seem to have
followed it with your "snap" subdirectory).
So you probably would want to either (1) readdir in .git/refs (to future
proof) or (2) drop refs/snap from the vicinity list for now (to not give
special treatment to JIT, which I myself do not mind ;-)). Also if you
go route (2) drop "refs" itself as well.
Actually, my code was intended to take things like "heads/master" or
"tags/linux-2.6.13", which are found under "refs/" (although I also check
that they don't start with "." and have exactly one "/", to enforce the
naming system). Making it "heads/linus" rather than "linus" is important
for writing the files, since you can't guess reliably what subdirectory
the user means; also, it is easier for dealing with HTTP servers, where
you don't know what to ask for.
-Daniel
*This .sig left intentionally blank*