Re: [PATCH 0/2] tagsize < 8kb restriction

From: Linus Torvalds <torvalds@osdl.org>
Date: May 23, 2006, 00:02 UTC
Message-ID: <Pine.LNX.4.64.0605221646540.3697@g5.osdl.org>
In-Reply-To: <BAYC1-PASMTP1164FE2A24B4D1B4C0A607AE9A0@CEZ.ICE>

On Mon, 22 May 2006, Sean wrote:

Show 9 quoted lines

> What seems to becoming clear as more people find new ways to use
> git is that many of them would be well served by having a solid
> infrastructure to handle metadata.  Consider the case above: _git_
> itself doesn't need a structural reference, but users and external
> applications definitely need to be able to lookup which metadata
> is associated with any given commit.  Having a git standard for
> this type of data would help.  Tags already do this, so they're
> likely to be used and abused in ways not initially envisioned,
> just because git doesn't have another such facility.

I definitely think we should allow arbitrary tags.

That said, I think that what you actually want to do may be totally different.

If _each_ commit has some extra information associated with it, you don't want to create a tag that points to the commit, you more likely want to create an object that is indexed by the commit ID rather than the other way around.

IOW, I _think_ that what you described would be that if you have the commit ID, you want to find the data based on that ID. No?

And that you can do quite easily, while _also_ using git to distribute the extra per-commit meta-data. Just create a separate branch that has the data indexed by commit ID. That could be as simple as having one file per commit (using, perhaps, a similar directory layout as the .git/objects/ directory itself), and then you could do something like

	# Get the SHA1 of the named commit
	commit=$(git-rev-parse --verify "$cmitname"^0)

	# turn it into a filename (slash between two first chars and the rest)
	filename=$(echo $commit | sed 's:^\(..\)\(.*\):\1/\2:')

	# look it up in the "annotations" branch
	git cat-file blob "annotations:$filename"

which gets the data from the "annotations" branch, indexed by the SHA1 name.

Now, everybody can track your "annotations" branch using git, and get your per-commit annotations for the main branch.

See?

The real advantage of tags is that you can use them for the SHA1 expressions, and follow them automatically. If that's what you want (ie you don't want to index things by the commit SHA1, but by some external name, like the name the commit had in some other repository), then by all means use tags. But if you just want to associate some data with each commit, the above "separate branch for annotations" approach is much more efficient.

		Linus