Re: [RFC PATCH] Re: Empty directories...

[Nix <nix@esperi.org.uk>]

On 23 Jul 2007, Linus Torvalds spake thusly:
> So practically speaking, you want to track the *minimal* possible state, 
> not the maximal one. 

I think it depends on your use case. For source code and indeed anything
with heavy merges, this is true: but I'm increasingly using git as a
sort of `merged historical tar' to store images of entire random
filesystem trees across time, and gaining the benefit of the packer's
lovely space-efficiency as well (doing this with svn would be a lost
cause, twice the space usage before you even think about the
repository). And in that case, preserving everything you can makes
sense.

(Perhaps what I should be doing is tarring the directory tree up and
storing the *tarball* in git. I'll try that and see what it does to pack
sizes. These are version-controlled backups of my mother's magnum opus
in progress so you can understand that I don't want to destroy them
accidentally: I'd never hear the end of it! ;) )

> So this does mean that if you want to explicitly track certain things 
> (ownership and more complete file permissions, or ACL's, or "resource 
> forks", or any number of other things that a file *could* have on various 
> systems), you end up havign to track them in something else than git, or 
> you end up having to track them as a separate "metadata file".

Yes indeed: that's why I proposed doing this using a couple of new hooks
driving entirely optional permissions-preservation stuff. Most use cases
really won't want to track this, so this sort of stuff shouldn't impose
upon the git core or upon anyone who doesn't want it. (However, the
ability to have alternative file merging strategies *may* be useful
elsewhere, perhaps.)