Re: Storing commits in trees

[Peter Collingbourne <peter@pcc.me.uk>]

On Thu, Apr 15, 2010 at 10:32:12PM +0200, Joachim Breitner wrote:
> [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