From: Linus Torvalds Date: Tue, 03 May 2005 19:02:33 GMT Subject: Re: git and symlinks as tracked content Message-ID: In-Reply-To: <1115145234.21105.111.camel@localhost.localdomain> On Tue, 3 May 2005, Kay Sievers wrote: > > Is there a sane model to make git aware of tracking symlinks in the > repository? In the bk udev tree we've had a test sysfs-tree with a lot > of symlinks in it. > > Where can we store the link-target? In its own blob-object or directly > in the tree-object? I'd suggest you create a blob object with the symlink name, and then in the tree you point to that blob, but with the S_IFLNK value in the mode field (0120000). 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. 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). That should cover most of it. > How would a exported "patch" with symlinks as content look like? The easiest way is to make this exactly the same as the "executable bit". A symlink is just a normal blob, it just has a "symlink mode" instead of "0755" or "0644" mode. When you think of it that way, the "patch" ends up falling out very naturally, I think. It would look like New file: filename (Mode: 0120000) --- /dev/null +++ filename @@ 0,0 1,1 +symlink-value (or something, you get the idea). Linus