[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@xxxxxxxxxxxxxxxxxxx | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@xxxxxxxxxxxxxxxxxxx | http://www.joachim-breitner.de/ Debian Developer: nomeata@xxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part