On Mon, Aug 20, 2007 at 20:48:29 +0200, Mike Hommey wrote: > On Mon, Aug 20, 2007 at 08:40:13PM +0200, David Kastrup <dak@xxxxxxx> wrote: > > Mike Hommey <mh@xxxxxxxxxxxx> writes: > > > > > On Mon, Aug 20, 2007 at 07:58:43PM +0200, David Kastrup <dak@xxxxxxx> wrote: > > >> > I also never understood why there were no permissions set on > > >> > directories in trees... > > >> > > >> Because directories are not actually tracked. They are created and > > >> deleted as-needed. > > > > > > I don't see why it would prevent to have a permission set to > > > it... the permission technically can be recorded in the parent tree, > > > along its sha1. Filesystems are also like this. > > > > No, they aren't. Filesystems don't create and delete directories on > > the fly. If we record any information about a directory, deleting it > > automagically would not be appropriate since we would lose information > > that has not been explicitly deleted. > > git doesn't magically create directories either. It actually stores > something about them: the hash of the tree object that represents them. > And it has permissions associated with these hashes. > > What it doesn't have, though, is tracking of the directory's history. Git does not have tracking of file's history either. There are actually no permissions to record with a directory, since only executable bit is tracked and that always has to be turned on. Git actually does store directories in tree objects, but never in the index. There was a long thread about tracking existence of directories. IMNSHO the index can start to *always* contain directories, with reader being able to detect index written without them and automatically fill them in, to keep compatibility. Than a config option could switch between removing empty directories implicitly when there are no versioned files in them, or explicitely. -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
