On Wed, 26 Jul 2006, Nix wrote: > > Well, actually I was considering trying a combination of two things: > > - a new type of multi-entry ref (as you suggested), perhaps in a file > refs/inactive-heads, which is merged with the heads list by lookup > operations only (so merge would see them, but ls-remote would not: > `invisible heads' if you will) Yes, that should work. Make sure that you tell git-fsck-objects and git-prune that those heads are reachable, though. Of course, if you end up having one "master" head (that is the "merge" of all branches), that would take care of the reachability issue too: you don't actually need to create a _real_ merge, you can just make sure that there is a commit that points to all new heads you create. It could even have a totally dummy tree node, ie you could do oldhead=$(git-rev-parse HEAD^0) || exit newhead=$(git commit-tree $oldhead -p $oldhead -p new-bug-head < changelog) || exit git update-ref HEAD $newhead $oldhead which would just update the commit list with a fake "merge" commit merging "new-bug-head" into the stream of top commits (using the same tree as the previous "HEAD" commit had) so that it's always reachable. Something like that, anyway. That way you can do a "git clone" and you get all the bug commits through a single HEAD. Linus - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html