Re: git and symlinks as tracked content
- From
Linus Torvalds <torvalds@osdl.org>
- Date
- May 3, 2005, 19:02 UTC
- Message-ID
- <Pine.LNX.4.58.0505031151240.26698@ppc970.osdl.org>
- In-Reply-To
- <1115145234.21105.111.camel@localhost.localdomain>
On Tue, 3 May 2005, Kay Sievers wrote:
Show 7 quoted lines
> > 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