Kudos for the complete answer. Very insightful. On Dec 7, 2012 11:20 AM, "Konstantin Khomoutov" < [email protected]> wrote:
> On Fri, 7 Dec 2012 08:48:41 -0800 (PST) > John McKown <[email protected]> wrote: > > > That's the question. Or I really am not understanding what all is in > > there. But what I understand (if correct) is that the files > > in .git/objects are such that the subdirectory name is the first two > > hex characters of the SHA1SUM value of the contents, the file name > > within that subdirectory are the last 38 characters. And the contents > > of the file are a compressed version of the data. > > That's just an implementation detail which does not really affect the > way Git works from the standpoint of its user. > Also note that when the number of objects and commits grow, Git starts > to organise them into the so-called "pack files", so the number of > those "loose" objects is not usually high. The same applies to > references (branches and tags) which might get "archived" as well, when > Git thinks they should be. As with packed object, this is transparent > to the users and higher-level Git tools. > > > In any case, once > > the file is created, the contents are never updated. In fact, if they > > were updated, git would likely be royally messed up. If the original > > file is modified, a new SHA1SUM file is generated. So, why doesn't > > git just mark the files as "read only"? > > First, there's the question of filesystem semantics. > That "read only" attribute found on FATs (or maybe earlier filesystems) > actually compensated for complete lack of any access controls (and > user identities in the OS, for that matter) which are typically used > novadays to restrict access to files. These attributes were carried to > NTFS to provide backward compatibility. > Outside of FAT and NTFS, I know that extN filesystems implemented by the > Linux kernel support a set of attributes as well, but this set is > different from Microsoft filesystems. extN supports the so-called > "immutable" attribute which is sort-of equivalent to "read only". > > Note that the standard C library which defines those lowest-level > file-manipulation functions like open(2), do not mention file > attributes. > > What I try to convey, is that there's no such thing as a universally > available and agreed-upon convention about supporting "read only" > attributes on files; hence to implement it, Git would have to maintain > a list of "known" filesystems and be able to use filesystem-specific > methods to manipulate attributes on those files. > > But now consider that if Git (running under the same credentials as > you, the logged in user) is able to set that "read only" attribute on a > file, you still have full privileges to unset it, hence this kind of > "protecting" would be just a single level of fool-proofing and nothing > more. Say, imagine a standard Windows Explorer dialog for deleting > files -- if it would encounter a file marked as read only, it would ask > you if you really sure to delete that file, and I don't think I have to > assure you that most users just click through all those nagging dialogs > which get in thir way. So really, implementing this sort of protection > is too much trouble for too little reason. > > The primary way to protect your Git repository is to have backups. > Naturally, with Git (as with any DVCS), this could just amount to > periodically mirroring your changes to some offsite repository. > > Naturally, if several developers are working on a project, each having > their own private clone on their own hardware, the project becomes > really hard to kill completely as if someone thrashes their repository, > they could just re-clone it from someone else's copy. > > If you're worried about what happens if someone/something > deletes/modifies a Git object and this goes unnoticed, then it's not > that bad either: > 1) When doing certain operations, Git does re-check hashes of objects > it manipulates. > 2) Git has the `git fsck` program, which is able to perform thorough > analysis of a Git repository, so if you have any doubts, you could > just run it on a suspicious repository. > > -- > > > --
