Storing commits in trees

[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?

Thanks,
Joachim

[1] http://git-dpm.alioth.debian.org/

Joachim "nomeata" Breitner
  mail: [email protected] | ICQ# 74513189 | GPG-Key: 4743206C
  JID: [email protected] | http://www.joachim-breitner.de/
  Debian Developer: [email protected]

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