From: Daniel Barkalow Date: Sun, 24 Apr 2005 21:14:07 GMT Subject: Re: [RFC] Design of name-addressed data portion Message-ID: In-Reply-To: <20050424205438.GN1507@pasky.ji.cz> On Sun, 24 Apr 2005, Petr Baudis wrote: > Dear diary, on Sun, Apr 24, 2005 at 08:17:23PM CEST, I got a letter > where Daniel Barkalow told me that... > > 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/ ? Fine with me. I guess you can't just hit tab when writing a script. :) > > 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/. That seems to encourage confusion with the local/remote repository contrast. I think branch/ or fork/ would be more clear. Putting it in a directory doesn't seem so important to me, since it won't be shared anyway. (The reason I want info/ is so that you just symlink info/ to the master info/, and you don't have to remember to make a link for each file). -Daniel *This .sig left intentionally blank*