[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: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C
  JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/
  Debian Developer: nomeata@debian.org