Re: git and symlinks as tracked content

Linus Torvalds wrote:
 >Also, right now git will actually ignore most of the permission bits 
too.  
 >We can change that, and make it a dynamic setting somewhere (some flag in
 >a ".git/settings" file or something), but it does boil down to the fact
 >that a software development tree tracker wants different things than
 >something that tracks system settings.
...
 >So if you want to track system files, right now "raw git" is _not_ the 
way
 >to do it. You'd want something else.
...
 >But if you'd want to track other system directories with git, you'd
 >probably need to either (a) do serious surgery on git itself, or (probably
 >preferable) by (b) track the extra things you want "manually" using a file
 >(that is tracked in git) that describes the ownership and permission data.
 >
 >Whether git is really suitable for tracking non-source projects is
 >obviously debatable. It's not what it was designed for, and it _may_ be
 >able to do so partly just by luck.

I suspect there's a 95% point which is easily achieved, & beyond that it's not clear it's worth it.

I recall seeing several source code directories that actually use symlinks in their source, and thus would want them preserved by the SCM. (Not arguing that's the BEST plan, merely an observation). As this discussion has noted, that wouldn't be hard to add symlink support to git, and WOULD be helpful for its primary purpose as SCM support.

Once you're there, it wouldn't be hard to add logic to add options to (1) record the REAL permission bits, (2) record "." files, and (3) recover the permission bits. That would be enough to store & recover in a distributed way a single person's home directory. THAT might be darn useful, for those of us who float between different systems & would like to use a single system for multiple purposes. That's clearly beyond the scope of a typical SCM, but since it's easy to get there, that'd make sense.

I'm ambivalent about supporting dev, uid/gid, and mtime, and how it should be done; that may be beyond the "worth it" step.

--- David A. Wheeler