Kudos for the complete answer. Very insightful.
On Dec 7, 2012 11:20 AM, "Konstantin Khomoutov" <
flatw...@users.sourceforge.net> wrote:

> On Fri, 7 Dec 2012 08:48:41 -0800 (PST)
> John McKown <john.archie.mck...@gmail.com> 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