{"thread":{"id":"373","subject":"RT[0/3]: Some related random thoughts","startedAt":"2005-04-28T12:59:44Z","lastAt":"2005-04-29T00:11:23Z","messageCount":5,"participants":["Kris Shannon"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"2030","messageId":"5d4799ae0504280559109cd00e@mail.gmail.com","threadId":"373","inReplyTo":null,"subject":"RT[0/3]: Some related random thoughts","fromName":"Kris Shannon","fromEmail":"kris.shannon.kernel@gmail.com","sentAt":"2005-04-28T12:59:44Z","receivedAt":"2005-04-28T12:59:44Z","isPatch":false,"sender":{"key":"kris.shannon.kernel@gmail.com","avatar":null},"body":"I've had a number of thoughts about the \"supposed\" missing SCM features of git.\n\n1) Alternate Encodings (including on-disk delta compression)\n If the default objects filename doesn't exist, we can try for\nother alternative\n encodings e.g. 00/a29c403e751c2a2a61eb24fa2249c8956d1c80.xdelta which\n can specify the object content as a delta or other ingenious idea...\n\n2) Rename/Code-movement Tracking (file and/or function)\n Additional object type tag(s) \"rename\" which references a changeset\n and lists the movement metadata\n\n3) SHA1 backwards reference cache\n Allows quickly finding all commits which reference a given tree root,\n all/the \"rename\" for a given commit, all xdeltas which use this blob.\n\nThere a quite a few important issues with all 3 of these ideas so I\nthought I would\nelaborate each in separate emails... (coming soon :)\n\n-- \nKris Shannon \n"},{"id":"2034","messageId":"5d4799ae05042806344aa9d75f@mail.gmail.com","threadId":"373","inReplyTo":"5d4799ae0504280559109cd00e@mail.gmail.com","subject":"RT[2/3]: Rename/Code-movement Tracking","fromName":"Kris Shannon","fromEmail":"kris.shannon.kernel@gmail.com","sentAt":"2005-04-28T13:34:15Z","receivedAt":"2005-04-28T13:34:15Z","isPatch":false,"sender":{"key":"kris.shannon.kernel@gmail.com","avatar":null},"body":"IMO adding a new object type tag (or tags) for tracking would fit the git model.\n\nCall it \"rename\" for example (better yet think of a better name)\nLet the contents be something along the lines of:\n\ncommit CHANGESET-SHA1\nPARENT-TREE-SHA1 /old/path\\0/new/path\\0\nPARENT-TREE-SHA1 /old/path/2\\0/new/path/2\\0\n...\n\nThe exact details will depend on the renaming model and I don't care to\nmuch at the moment what that turns out to be.\n\nThis new tag allows the rename data to be added on to commit's from people\nlike linus who don't care about rename.\n\nIt doesn't reduce security because any can happen to the rename object\nand that will cover the whole commit (and those who sign the commit are\nobviously not validating any rename information)\n\nThe rename objects can be used to assist in automatic merging but from my\nexperience I would agree with linus that if the right way to merge is not\nreally obvious then you probably need user input anyway.\n\n-- \nKris Shannon \n"},{"id":"2036","messageId":"5d4799ae05042806477eb1e222@mail.gmail.com","threadId":"373","inReplyTo":"5d4799ae0504280559109cd00e@mail.gmail.com","subject":"RT[1/3]: Alternate Encodings (esp. Delta Compression)","fromName":"Kris Shannon","fromEmail":"kris.shannon.kernel@gmail.com","sentAt":"2005-04-28T13:47:59Z","receivedAt":"2005-04-28T13:47:59Z","isPatch":false,"sender":{"key":"kris.shannon.kernel@gmail.com","avatar":null},"body":"If a format is defined for representing delta compression then\nit would be prudent to make sure that it could be used for\nencoding both forward and backward deltas (not necessarily\nin the same delta :) These deltas could then by kept in the \nobjects directory (i.e. 00/a29c403e751c2a2a61eb24fa2249c8956d1c80.xdelta)\n\nDoing delta compression of old versions is something that should\nbe done manually (the subversion people have empirical data\nto back that up I think but I can't seem to find a link ATM)\nA command for wiping old versions from a repository to save space\ncould be altered to replace the files with their xdelta equivalents\nfor a reduced space savings but still keeping a full history.\n\nUsing delta compression of the new versions (against the old) for\nefficient bandwidth consumption is another possible area. If these\ndelta's are produced on the fly, they could be cached in the objects\ndirectory.\n\nThese two different use cases are IMO a good argument for\nusing this as a convention even if it doesn't become a part of git's\ncore (i.e. changing read_sha1_file to transparently expand xdelta's)\n\nIf you add .xdelta it would follow that other encodings might be useful,\nand added to the objects directory in the same way.\n\n-- \nKris Shannon \n"},{"id":"2037","messageId":"5d4799ae05042806544683b4c9@mail.gmail.com","threadId":"373","inReplyTo":"5d4799ae0504280559109cd00e@mail.gmail.com","subject":"RT[3/3]: Reverse lookup of SHA1 references","fromName":"Kris Shannon","fromEmail":"kris.shannon.kernel@gmail.com","sentAt":"2005-04-28T13:54:35Z","receivedAt":"2005-04-28T13:54:35Z","isPatch":false,"sender":{"key":"kris.shannon.kernel@gmail.com","avatar":null},"body":"There are a number of places where you want to find all the objects\nwhich reference this particular object. AIUI this is not currently an easy\ntask. Some thought should be put into how to make these reverse\nlookups fast.\n\nThe other two random thoughts would benefit greatly from a relationship\ncache.\n\nUmm.... I was going to write some more, but I've gotta go :(\n\nMore thoughts later...\n\n-- \nKris Shannon \n"},{"id":"2113","messageId":"5d4799ae0504281711669ef900@mail.gmail.com","threadId":"373","inReplyTo":"42717714.50601@dwheeler.com","subject":"Re: RT[3/3]: Reverse lookup of SHA1 references","fromName":"Kris Shannon","fromEmail":"kris.shannon.kernel@gmail.com","sentAt":"2005-04-29T00:11:23Z","receivedAt":"2005-04-29T00:11:23Z","isPatch":false,"sender":{"key":"kris.shannon.kernel@gmail.com","avatar":null},"body":"On 4/29/05, David A. Wheeler wrote:\n> Kris Shannon wrote:\n> > There are a number of places where you want to find all the objects\n> > which reference this particular object. AIUI this is not currently an easy\n> > task. Some thought should be put into how to make these reverse\n> > lookups fast.\n> I have. Please look at my old postings. It turns out to be easy;\n> just create a directory parallel to .git/objects, say:\n> .git/reverse\n> 00/\n> 89123408312904819048390/\n> 189412890892308290\n> 238923849038329089\n> \n> Anyway you get the idea.\n\nSeems reasonable.\n\n> Linus does NOT want renames noted; see the old emails on that.\n> It's not clear this is such a good idea, but he's adamant.\n> He thinks this can be handled by merge.\n> If not, it can be added later.\n\nI realize that this is not a priority for linus, I was suggesting that\nit be added as a separate object type. I think that many of the\nextra metadata could be usefully added as other object types.\nThese can be optional and/or added after the fact.\n\n> --- David A. Wheeler\n> \n\n-- \nKris Shannon \n"}]}