{"thread":{"id":"23485","subject":"Storing commits in trees","startedAt":"2010-04-15T20:32:12Z","lastAt":"2010-04-18T17:48:54Z","messageCount":2,"participants":["Joachim Breitner","Peter Collingbourne"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"139627","messageId":"1271363532.18164.47.camel@localhost","threadId":"23485","inReplyTo":null,"subject":"Storing commits in trees","fromName":"Joachim Breitner","fromEmail":"mail@joachim-breitner.de","sentAt":"2010-04-15T20:32:12Z","receivedAt":"2010-04-15T20:32:12Z","isPatch":false,"sender":{"key":"mail@joachim-breitner.de","avatar":"https://gravatar.com/avatar/1e9dd229978aa44811b44fc08a445cd1950a092f74fe2f5539d881f1c1b46fbf?d=mp&s=160"},"body":"[Please CC me on reply, as I’m not subscribed. Thanks!]\n\nHi,\n\nfor a variation of the workflow implemented by git-dpm[1], a tool to\nmanage the development of Debian packages in git, I wanted to refer to a\nspecific commit P from a regular commit D on my master branch, without P\nbeing a parent of D, as I don’t want it to show up in the history.\n\nI found out that I can store commit objects in a tree object, using git \n$ git update-index --add --cacheinfo 160000 0ac1855f1681c05d195f219c3003a05dc8d3ac20 stored-commits/some-commit\nand refer to it via HEAD:stored-commits/some-commit. I was happy, until\nI noticed that git prune will happily delete the stored commit as soon\nas it is not referred somewhere else, and git push/pull won’t transfer\nthe stored commit along the tree it is contained in.\n\nI then found out that storing commit objects in the tree is implemented\nfor git-submodules, where you in fact do not want to store the commit in\nthe main repo.\n\nNow I’m wondering if it would be feasible to offer this feature: A\nproper “commit” object within a tree that is walked by fsck_walk_tree\nand the other tree walkers?\n\nOr is there yet another way of telling git that commit D “depends on”\ncommit P?\n\nThanks,\nJoachim\n\n[1] http://git-dpm.alioth.debian.org/\n\n\n\n-- \nJoachim \"nomeata\" Breitner\n  mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C\n  JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/\n  Debian Developer: nomeata@debian.org\n"},{"id":"139822","messageId":"20100418174854.GA10132@pcc.me.uk","threadId":"23485","inReplyTo":"1271363532.18164.47.camel@localhost","subject":"Re: Storing commits in trees","fromName":"Peter Collingbourne","fromEmail":"peter@pcc.me.uk","sentAt":"2010-04-18T17:48:54Z","receivedAt":"2010-04-18T17:48:54Z","isPatch":false,"sender":{"key":"peter@pcc.me.uk","avatar":"https://avatars.githubusercontent.com/u/425024?v=4"},"body":"On Thu, Apr 15, 2010 at 10:32:12PM +0200, Joachim Breitner wrote:\n> [Please CC me on reply, as I’m not subscribed. Thanks!]\n> \n> Hi,\n> \n> for a variation of the workflow implemented by git-dpm[1], a tool to\n> manage the development of Debian packages in git, I wanted to refer to a\n> specific commit P from a regular commit D on my master branch, without P\n> being a parent of D, as I don’t want it to show up in the history.\n> \n> I found out that I can store commit objects in a tree object, using git \n> $ git update-index --add --cacheinfo 160000 0ac1855f1681c05d195f219c3003a05dc8d3ac20 stored-commits/some-commit\n> and refer to it via HEAD:stored-commits/some-commit. I was happy, until\n> I noticed that git prune will happily delete the stored commit as soon\n> as it is not referred somewhere else, and git push/pull won’t transfer\n> the stored commit along the tree it is contained in.\n> \n> I then found out that storing commit objects in the tree is implemented\n> for git-submodules, where you in fact do not want to store the commit in\n> the main repo.\n> \n> Now I’m wondering if it would be feasible to offer this feature: A\n> proper “commit” object within a tree that is walked by fsck_walk_tree\n> and the other tree walkers?\n> \n> Or is there yet another way of telling git that commit D “depends on”\n> commit P?\n\nHi Joachim,\n\nI encountered this problem while developing silt [1], another workflow\ntool for Debian packaging, which uses a similar technique to refer to\ncommits from a tree (in this case, from the packaging tree to patch\ncommits derived from upstream).\n\nI solved the problem by automatically creating a ref for each such\nreference.  The name of the ref contains a reference to the earliest\nunique commit on the branch (\"earliest\" is determined using the\ncommit date), to avoid cluttering the ref namespace every time the\nref changes.\n\nNot only does one need to remember to push the patch refs along with\nthe main branch ref, the code that determines the earliest unique\ncommit is error prone and I agree that what would be beneficial would\nbe a \"hard link\" to a commit.\n\nIn terms of implementation, perhaps we can store a value in the lower\norder bits of the mode which indicates whether this is a hard link?\nThis would ensure compatibility with older versions of git (S_ISGITLINK\nwould still hold for hard links).\n\n[1] http://git.debian.org/?p=users/pcc-guest/silt.git;a=summary\n\nThanks,\n-- \nPeter\n"}]}