# [RFC] Design of name-addressed data portion 5 messages from 2005-04-24 to 2005-04-24. Participants: Daniel Barkalow, Petr Baudis, Fabian Franz. Thread: https://gitlist.dev/t/292 ## Daniel Barkalow, 2005-04-24 18:17 Subject: [RFC] Design of name-addressed data portion Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.21.0504241336250.30848-100000%40iabervon.org ``` I think it has gotten to be time to have a standard mechanism for name-addressed data in the .git directory. We currently have one agreed-upon item, HEAD, as well as a number of items in cogito: heads, tags, and, to a certain extent, remotes. (Even in core git, when we support tags, we'll want a mapping from tag names to tag objects, even if this mapping doesn't get transferred by push and pull operations; nobody's going to want to cut and paste a hash from email every time they want to refer to the tag, and fsck-cache could stand to know which tags you mean to have so that it can report the rest to git-prune-script) 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). I'd propose the following structure: objects/ the content-addressed repository portion references/ the name-addressed repository portion 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 All of the files in references/*/* contain hex for objects in the database, and are not synced between repositories in situ (but some sync operations will read some of them and write them under different names). fsck-cache would use as its reachability starting point $(cat references/*/*). In info/ are, generically, other files that relate to operations which work on the repository rather than a working directory. Transfer programs would use and maintain this information. I think we'd still eventually want some way of getting from a commit-id to any tags about it (I think git log would do well to mention any tags you have when it shows a commit), but I don't want to design this quite yet. It should also work for going from the real history to cached delta info, when we have comparison tools that are sufficiently smart, expensive, and intermediate-dependant to want to cache this. -Daniel *This .sig left intentionally blank* ``` ## Petr Baudis, 2005-04-24 20:54 Subject: Re: [RFC] Design of name-addressed data portion Message-ID: <20050424205438.GN1507@pasky.ji.cz> URL: https://gitlist.dev/e/20050424205438.GN1507%40pasky.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 ``` ## Daniel Barkalow, 2005-04-24 21:14 Subject: Re: [RFC] Design of name-addressed data portion Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.21.0504241703060.30848-100000%40iabervon.org 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* ``` ## Fabian Franz, 2005-04-24 22:58 Subject: Re: [RFC] Design of name-addressed data portion Message-ID: <200504250058.15901.FabianFranz@gmx.de> URL: https://gitlist.dev/e/200504250058.15901.FabianFranz%40gmx.de In-Reply-To: ``` -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Sonntag, 24. April 2005 20:17 schrieb Daniel Barkalow: > I'd propose the following structure: > > [...] > tags/ the tags > ... files with the symbolic name of the tags, containing the hash Couldn't you use symbolic or hard links here and in references/? cu Fabian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCbCSHI0lSH7CXz7MRAmPDAJ95YVHaGWH3KIMhOrw035cAUZd+QgCfZqFa 8IAfnNgc8P6cx+W2+xNJ0P0= =WGC/ -----END PGP SIGNATURE----- ``` ## Daniel Barkalow, 2005-04-24 23:12 Subject: Re: [RFC] Design of name-addressed data portion Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.21.0504241903500.30848-100000%40iabervon.org In-Reply-To: <200504250058.15901.FabianFranz@gmx.de> ``` On Mon, 25 Apr 2005, Fabian Franz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am Sonntag, 24. April 2005 20:17 schrieb Daniel Barkalow: > > I'd propose the following structure: > > > > [...] > > tags/ the tags > > ... files with the symbolic name of the tags, containing the hash > > Couldn't you use symbolic or hard links here and in references/? For most uses of the refs/ directory (of which tags/ is a subdirectory), we want to get from it the hash, not just the contents of the referenced object, and we potentially want to get the hash from something like a web server. Finding out what http://.../foo.git/refs/heads/DEFAULT is a symlink (or, wrose, hard link) to so that you can decide if it's different from what you have would be a major pain. -Daniel *This .sig left intentionally blank* ```