{"thread":{"id":"292","subject":"[RFC] Design of name-addressed data portion","startedAt":"2005-04-24T18:17:23Z","lastAt":"2005-04-24T23:12:24Z","messageCount":5,"participants":["Daniel Barkalow","Petr Baudis","Fabian Franz"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"1537","messageId":"Pine.LNX.4.21.0504241336250.30848-100000@iabervon.org","threadId":"292","inReplyTo":null,"subject":"[RFC] Design of name-addressed data portion","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-24T18:17:23Z","receivedAt":"2005-04-24T18:17:23Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"I think it has gotten to be time to have a standard mechanism for\nname-addressed data in the .git directory. We currently have one\nagreed-upon item, HEAD, as well as a number of items in cogito: heads,\ntags, and, to a certain extent, remotes. (Even in core git, when we\nsupport tags, we'll want a mapping from tag names to tag objects, even if\nthis mapping doesn't get transferred by push and pull operations; nobody's\ngoing to want to cut and paste a hash from email every time they want to\nrefer to the tag, and fsck-cache could stand to know which tags you mean\nto have so that it can report the rest to git-prune-script)\n\nIt would be useful to have a bit more structure to the repository, such\nthat there are a fixed number of paths that hold all of the information\nabout the state of the repository, while the rest of the directory has\ninformation that is particular to a working directory's state (e.g.,\nindex).\n\n\n\nI'd propose the following structure:\n\n objects/ the content-addressed repository portion\n references/ the name-addressed repository portion\n heads/ the heads that are being used out of this repository\n DEFAULT the head that people pulling this repository mean by default\n ... other heads, by name, that fsck-cache should mark reachable\n tags/ the tags\n ... files with the symbolic name of the tags, containing the hash\n info/ other per-repository information\n remotes URLs of remote repositories\n complete hashes that the repository contains all references from\n missing hashes that the repository lacks but wants\n excluded hashes that the repository doesn't want\n ... other files are per .git directory, not shared on push/pull\n index \n HEAD symlink to the head that is the local default\n tracked remote that this working directory tracks\n\nAll of the files in references/*/* contain hex for objects in the\ndatabase, and are not synced between repositories in situ (but some sync\noperations will read some of them and write them under different\nnames). fsck-cache would use as its reachability starting point $(cat\nreferences/*/*).\n\nIn info/ are, generically, other files that relate to operations which\nwork on the repository rather than a working directory. Transfer programs\nwould use and maintain this information.\n\nI think we'd still eventually want some way of getting from a commit-id to\nany tags about it (I think git log would do well to mention any tags you\nhave when it shows a commit), but I don't want to design this quite\nyet. It should also work for going from the real history to cached delta\ninfo, when we have comparison tools that are sufficiently smart,\nexpensive, and intermediate-dependant to want to cache this.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"1544","messageId":"20050424205438.GN1507@pasky.ji.cz","threadId":"292","inReplyTo":"Pine.LNX.4.21.0504241336250.30848-100000@iabervon.org","subject":"Re: [RFC] Design of name-addressed data portion","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-24T20:54:38Z","receivedAt":"2005-04-24T20:54:38Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Apr 24, 2005 at 08:17:23PM CEST, I got a letter\nwhere Daniel Barkalow told me that...\n> It would be useful to have a bit more structure to the repository, such\n> that there are a fixed number of paths that hold all of the information\n> about the state of the repository, while the rest of the directory has\n> information that is particular to a working directory's state (e.g.,\n> index).\n\nAgreed.\n\n> \n> \n> I'd propose the following structure:\n> \n> objects/ the content-addressed repository portion\n> references/ the name-addressed repository portion\n\nreferences/ is just too long for my taste. ;-) What about just refs/ ?\n\n> heads/ the heads that are being used out of this repository\n> DEFAULT the head that people pulling this repository mean by default\n> ... other heads, by name, that fsck-cache should mark reachable\n> tags/ the tags\n> ... files with the symbolic name of the tags, containing the hash\n> info/ other per-repository information\n> remotes URLs of remote repositories\n> complete hashes that the repository contains all references from\n> missing hashes that the repository lacks but wants\n> excluded hashes that the repository doesn't want\n> ... other files are per .git directory, not shared on push/pull\n> index \n> HEAD symlink to the head that is the local default\n> tracked remote that this working directory tracks\n\nI will probably throw the local stuff to local/.\n\nI think I like this otherwise.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"1546","messageId":"Pine.LNX.4.21.0504241703060.30848-100000@iabervon.org","threadId":"292","inReplyTo":"20050424205438.GN1507@pasky.ji.cz","subject":"Re: [RFC] Design of name-addressed data portion","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-24T21:14:07Z","receivedAt":"2005-04-24T21:14:07Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 24 Apr 2005, Petr Baudis wrote:\n\n> Dear diary, on Sun, Apr 24, 2005 at 08:17:23PM CEST, I got a letter\n> where Daniel Barkalow told me that...\n> > I'd propose the following structure:\n> > \n> > objects/ the content-addressed repository portion\n> > references/ the name-addressed repository portion\n> \n> references/ is just too long for my taste. ;-) What about just refs/ ?\n\nFine with me. I guess you can't just hit tab when writing a script. :)\n\n> > heads/ the heads that are being used out of this repository\n> > DEFAULT the head that people pulling this repository mean by default\n> > ... other heads, by name, that fsck-cache should mark reachable\n> > tags/ the tags\n> > ... files with the symbolic name of the tags, containing the hash\n> > info/ other per-repository information\n> > remotes URLs of remote repositories\n> > complete hashes that the repository contains all references from\n> > missing hashes that the repository lacks but wants\n> > excluded hashes that the repository doesn't want\n> > ... other files are per .git directory, not shared on push/pull\n> > index \n> > HEAD symlink to the head that is the local default\n> > tracked remote that this working directory tracks\n> \n> I will probably throw the local stuff to local/.\n\nThat seems to encourage confusion with the local/remote repository\ncontrast. I think branch/ or fork/ would be more clear. Putting it in a\ndirectory doesn't seem so important to me, since it won't be shared\nanyway. (The reason I want info/ is so that you just symlink info/ to the\nmaster info/, and you don't have to remember to make a link for each\nfile).\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"1557","messageId":"200504250058.15901.FabianFranz@gmx.de","threadId":"292","inReplyTo":"Pine.LNX.4.21.0504241336250.30848-100000@iabervon.org","subject":"Re: [RFC] Design of name-addressed data portion","fromName":"Fabian Franz","fromEmail":"fabianfranz@gmx.de","sentAt":"2005-04-24T22:58:13Z","receivedAt":"2005-04-24T22:58:13Z","isPatch":false,"sender":{"key":"fabianfranz@gmx.de","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nAm Sonntag, 24. April 2005 20:17 schrieb Daniel Barkalow:\n> I'd propose the following structure:\n>\n> [...]\n> tags/ the tags\n> ... files with the symbolic name of the tags, containing the hash\n\nCouldn't you use symbolic or hard links here and in references/?\n\ncu\n\nFabian\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.2.4 (GNU/Linux)\n\niD8DBQFCbCSHI0lSH7CXz7MRAmPDAJ95YVHaGWH3KIMhOrw035cAUZd+QgCfZqFa\n8IAfnNgc8P6cx+W2+xNJ0P0=\n=WGC/\n-----END PGP SIGNATURE-----\n\n"},{"id":"1559","messageId":"Pine.LNX.4.21.0504241903500.30848-100000@iabervon.org","threadId":"292","inReplyTo":"200504250058.15901.FabianFranz@gmx.de","subject":"Re: [RFC] Design of name-addressed data portion","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-24T23:12:24Z","receivedAt":"2005-04-24T23:12:24Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 25 Apr 2005, Fabian Franz wrote:\n\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> Am Sonntag, 24. April 2005 20:17 schrieb Daniel Barkalow:\n> > I'd propose the following structure:\n> >\n> > [...]\n> > tags/ the tags\n> > ... files with the symbolic name of the tags, containing the hash\n> \n> Couldn't you use symbolic or hard links here and in references/?\n\nFor most uses of the refs/ directory (of which tags/ is a subdirectory),\nwe want to get from it the hash, not just the contents of the referenced\nobject, and we potentially want to get the hash from something like a web\nserver. Finding out what http://.../foo.git/refs/heads/DEFAULT is a\nsymlink (or, wrose, hard link) to so that you can decide if it's different\nfrom what you have would be a major pain.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"}]}