On Thu, Oct 21, 2010 at 5:58 PM, Dun Peal <[email protected]> wrote:
> > I won't ask... > > We tag each release. We follow "release early, release often". So, we > have many tags. > Ah, okay, thanks for telling even if I didn't ask then :-) > I suppose the right thing to do is to only display a subset of the tags, > > which would require a UI to search/browse the tags. > > Yes. Would you accept a patch that does that? > Sure. One way to solve it could be to use a folder-like convention for tags. For instance I could create the tag releases/v1 - and we could treat these as "folders" in the UI and add functionality for listing all tags within one of these "folders". Just an idea I got, does it make any sense? > Hm, can you clarify? The tags are physically stored in one long text > file: `.git/packed-refs`. So for us, that file does contain several > tens of thousands of lines, but I'm not sure that would be a > performance problem, seeing that it's just reading a file with a few > tens of thousands of lines, which shouldn't tax modern hardway. > >From the top of my mind, Grit (the Ruby/Git library we're using) will create a Tag object for each tag that's fetched, which would mean a few thousand object instantiations for each request - this may or may not have a performance penalty. If we choose to go with the folder convention, we could have the tag fetching code accept a parameter that filters which Tag objects get instantiated - but it may not be a problem at all. At least one that caching the tags wouldn't solve. Cheers, - Marius -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected]
