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

[Sean <seanlkml@sympatico.ca>]

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

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

> 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