From: Petr Baudis Date: Sun, 24 Apr 2005 20:54:38 GMT Subject: Re: [RFC] Design of name-addressed data portion Message-ID: <20050424205438.GN1507@pasky.ji.cz> In-Reply-To: Dear diary, on Sun, Apr 24, 2005 at 08:17:23PM CEST, I got a letter where Daniel Barkalow told me that... > It would be useful to have a bit more structure to the repository, such > that there are a fixed number of paths that hold all of the information > about the state of the repository, while the rest of the directory has > information that is particular to a working directory's state (e.g., > index). Agreed. > > > I'd propose the following structure: > > objects/ the content-addressed repository portion > references/ the name-addressed repository portion references/ is just too long for my taste. ;-) What about just refs/ ? > heads/ the heads that are being used out of this repository > DEFAULT the head that people pulling this repository mean by default > ... other heads, by name, that fsck-cache should mark reachable > tags/ the tags > ... files with the symbolic name of the tags, containing the hash > info/ other per-repository information > remotes URLs of remote repositories > complete hashes that the repository contains all references from > missing hashes that the repository lacks but wants > excluded hashes that the repository doesn't want > ... other files are per .git directory, not shared on push/pull > index > HEAD symlink to the head that is the local default > tracked remote that this working directory tracks I will probably throw the local stuff to local/. I think I like this otherwise. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor