Re: [PATCH 0/5] More ref logging

[Sean <seanlkml@sympatico.ca>]

On Sat, 20 May 2006 20:50:09 -0400
Shawn Pearce <spearce@spearce.org> wrote:

> It sort of is a new way of tagging commits with extra data.  But its
> also sort of a way of versioning your ref `database'.  Using tags
> to save the points in time might be useful but it would generate
> a lot of temporary files.  A commit every 5 minutes for a typical
> working week would generate 480 tags per week.  That's just too much.

But isn't that just an implementation detail?  I've actually run
into another situation where tags would be perfect if only they weren't
so expensive (ie. entire repo was in a 50Mb pack including tag objects,
but the .git/refs/tags directory was over 100Mb).

So, if we found a way to store tags more efficiently your 480 tags per
week shouldn't be a problem at all.   The main point being to extend
and optimize the existing infrastructure rather than bolting on a new
class of objects (ie. ref log) which only serves a narrow (albeit
important) purpose.
 
> I was actually thinking this morning that another way to do this
> is to keep a metadata branch within the repository which records
> all of the refs in tree objects, then save the root commit under
> the special ref `LOG` in GIT_DIR.  Every update to a logged ref
> would cause the tree to be updated and a new commit to be built.
> The branch would be a relatively simple string of pearls as its
> doubtful you would branch it.
>
> There are a number of downsides to this, not the least of which is
> I'd like to put a commit or tag SHA1 into the tree object rather than
> writing each ref as a blob (saves space).  Currently commits and tags
> aren't permitted in a tree object so that would require some effort.
> But on the other hand you could pull (and track!) someone elses
> ref log through the standard GIT protocol.
 
Yes, Linus proposed something similar earlier to hold meta data.
But i've come to see tags as a place to store any arbitrary meta
data associated with a commit.   If their implementation was more
efficient you could use them for your project and they could be used
for any number of other purposes as well.

> But this is starting to head down into the `bind commit` discussion;
> how do we record a number of commits as being related and tie them
> up into a single super commit?

Well, a tag that allowed the listing of multiple heads....

Sean