Re: git and symlinks as tracked content

From: H. Peter Anvin <hpa@zytor.com>
Date: May 3, 2005, 19:50 UTC
Message-ID: <4277D609.5050701@zytor.com>
In-Reply-To: <Pine.LNX.4.58.0505031151240.26698@ppc970.osdl.org>

Linus Torvalds wrote:

Show 10 quoted lines

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

Show 10 quoted lines

> 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