Re: Storing commits in trees

From: Peter Collingbourne <peter@pcc.me.uk>
Date: Apr 18, 2010, 17:48 UTC
Message-ID: <20100418174854.GA10132@pcc.me.uk>
In-Reply-To: <1271363532.18164.47.camel@localhost>

On Thu, Apr 15, 2010 at 10:32:12PM +0200, Joachim Breitner wrote:

Show 26 quoted lines

> [Please CC me on reply, as I’m not subscribed. Thanks!]
> 
> Hi,
> 
> for a variation of the workflow implemented by git-dpm[1], a tool to
> manage the development of Debian packages in git, I wanted to refer to a
> specific commit P from a regular commit D on my master branch, without P
> being a parent of D, as I don’t want it to show up in the history.
> 
> I found out that I can store commit objects in a tree object, using git 
> $ git update-index --add --cacheinfo 160000 0ac1855f1681c05d195f219c3003a05dc8d3ac20 stored-commits/some-commit
> and refer to it via HEAD:stored-commits/some-commit. I was happy, until
> I noticed that git prune will happily delete the stored commit as soon
> as it is not referred somewhere else, and git push/pull won’t transfer
> the stored commit along the tree it is contained in.
> 
> I then found out that storing commit objects in the tree is implemented
> for git-submodules, where you in fact do not want to store the commit in
> the main repo.
> 
> Now I’m wondering if it would be feasible to offer this feature: A
> proper “commit” object within a tree that is walked by fsck_walk_tree
> and the other tree walkers?
> 
> Or is there yet another way of telling git that commit D “depends on”
> commit P?

Hi Joachim,

I encountered this problem while developing silt [1], another workflow tool for Debian packaging, which uses a similar technique to refer to commits from a tree (in this case, from the packaging tree to patch commits derived from upstream).

I solved the problem by automatically creating a ref for each such reference. The name of the ref contains a reference to the earliest unique commit on the branch ("earliest" is determined using the commit date), to avoid cluttering the ref namespace every time the ref changes.

Not only does one need to remember to push the patch refs along with the main branch ref, the code that determines the earliest unique commit is error prone and I agree that what would be beneficial would be a "hard link" to a commit.

In terms of implementation, perhaps we can store a value in the lower order bits of the mode which indicates whether this is a hard link? This would ensure compatibility with older versions of git (S_ISGITLINK would still hold for hard links).

[1] http://git.debian.org/?p=users/pcc-guest/silt.git;a=summary

Thanks,

-- 
Peter