On 20/05/2015 14:44, Vladimír Čunát wrote: > On 05/19/2015 07:36 PM, Matthias Beyer wrote: >> On 19-05-2015 12:08:30, Vladimír Čunát wrote: >>> I'm uncertain if there might be some performance implications [...] >> >> From a git point of view, there won't be any performance implications >> besides that the tags get fetched on `git fetch` - which is wanted >> behaviour I guess. > > What I meant: in most git commands one can specify a <refname>, so any > tag is accepted there as well. Therefore, the tags probably have to be > searched very often (see "man gitrevision" for details). > > I think the implementation does no clever thing about the tag/branch > names - it just passes through all, which could become slower in time, > if we had many thousands of them.
That I/O for getting all refs can indeed become very noticeable if the local git repository is not in the FS cache, also somewhat depending on the file system that's used. But there is already a solution for that: git pack-refs stores the refs (tags only, by default) in a single file, rather than as a separate file for each ref. Separate files will still be created as refs get updated, but only for those refs that get updated. git pack-refs is by default automatically run by git gc, and git gc is by default automatically run after most operations, if enough git objects have been created. So for most users, as long as you make sure to use tags and not some custom ref naming scheme, nothing special needs to be done. Cheers, Harald van Dijk > But anyway, IMO it will take some time before it gets noticeable. I > often check out all the pull request branches, so I have thousands refs > already, without noticing any problems. > > $ wc -l .git/info/refs && du -h .git/info/refs > 6701 .git/info/refs > 420K .git/info/refs > > $ find .git/refs/ | wc -l > 587 > > > Vladimir _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev