Re: git and symlinks as tracked content

["H. Peter Anvin" <hpa@zytor.com>]

Linus Torvalds wrote:
> 
> So you have
> 
>  - directories: S_IFDIR (0040000) point to "tree" objects for contents
>  - symlinks: S_IFLNK (0120000) point to "blob" objects
>  - executables: S_IFREG | 0755 (0100755) point to "blob" objects
>  - regular files: S_IFREG | 0644 (0100644) point to "blob" objects
> 
> which seems very sane and regular. 
> 

One thing about using a hierarchy of "tree" objects... as far as I 
understand today, it's possible for "git" to represent a limited 
scattering of files underneath the root, such as keeping one's 
configuration files underneath one's home directory.  Scanning the whole 
home directory to check in (or worse, out) files would suck.

On the other hand, having a single "tree" object for a large project 
that would have to be constantly updated would suck, too.

This is certainly *not* mutually exclusive; it's mostly a matter of 
making sure that if scaffolding directory objects are necessary, that 
they can be automatically added/created, and aren't exhaustively 
searched for uncontrolled objects.

> Now, I also haev a plan for device nodes, but that one is so ugly that I'm 
> a bit ashamed of it. That one does:
> 
>  - S_IFCHR/S_IFBLK (0020000 or 0060000), with the 20-byte SHA1 not being a 
>    SHA1 at all, but just the major:minor numbers in some nice binary 
>    encoding. Probably: two network byte order 32-bit values, with twelve 
>    bytes of some non-zero signature (the SHA1 of all zeroes should be 
>    avoided, so the signature really should be soemthing else than just 
>    twelve bytes of zero).
> 

OK, that's ugly.  I'm impressed.  :)

	-hpa