Thanks for just a complete answer. I keep forgetting that some people run 
inferior systems, such as Windows <grin/>

On Friday, December 7, 2012 11:20:32 AM UTC-6, Konstantin Khomoutov wrote:
> On Fri, 7 Dec 2012 08:48:41 -0800 (PST) 
> John McKown < <javascript:>> 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. 


Reply via email to