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

From: Sean <seanlkml@sympatico.ca>
Date: May 23, 2006, 09:59 UTC
Message-ID: <BAYC1-PASMTP07A0CAD58FB1CE30882F19AE9B0@CEZ.ICE>
In-Reply-To: <Pine.LNX.4.64.0605221646540.3697@g5.osdl.org>

On Mon, 22 May 2006 17:02:41 -0700 (PDT) Linus Torvalds <torvalds@osdl.org> wrote:

Show 10 quoted lines

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

Correct. But even though there isn't currently an efficient way to do the reverse lookup, many of the visual tools do it. So for instance, if you embed some metadata in the name of a tag, it will actually be nicely shown to you associated with the proper commit in qgit/gitk/gitweb. So you _can_ abuse tags and get modest results. And of course the low level tools let you do.. git name-rev --tags to lookup the meta data as well. So you can do git log | git name-rev --tags --stdin and see which tags are associated with each commit.

I'm not arguing that this makes tags well designed for the these types of things, just that there is no other option built in to the low level git that comes as close.

Show 22 quoted lines

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

Sure, makes a lot of sense. Although the one file per commit thing doesn't scale well. It's already a problem when trying to use a lot of tags for instance.

More than the technical details of the implementation though, i'm trying to make a case that git would do well to codify something like the above and provide a _standard_ method of associating meta data with commits. This would allow all the tools to start displaying meta data etc and have a defined way to efficiently query and manipulate it.

Sean