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.) - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
