Sean <seanlkml@xxxxxxxxxxxx> wrote: > On Sat, 20 May 2006 20:50:09 -0400 > Shawn Pearce <spearce@xxxxxxxxxxx> 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). Any chance we could get some details on why so many tags were useful? You have a good argument here but I'm not sure how a better tag store could be structured. :-) > 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. Yea - despite being the author of ref log I'm still slightly unhappy with the fact that it doesn't make reuse of existing GIT plumbing. But I'm sort of OK with that right now as you can't map two indexes into memory at once currently, nor is there a way to easily update multiple refs at once if the ref log must serialize access to create a string of trees and commits. -- Shawn. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html