Re: Handling very large numbers of symbolic references?

From: Linus Torvalds <torvalds@osdl.org>
Date: Jul 25, 2006, 23:20 UTC
Message-ID: <Pine.LNX.4.64.0607251612480.29649@g5.osdl.org>
In-Reply-To: <87psftb7v8.fsf@hades.wkstn.nix>

On Wed, 26 Jul 2006, Nix wrote:

Show 7 quoted lines

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