[llvm-dev] [cfe-dev] [lldb-dev] Sequential ID Git hook
Tom Honermann via llvm-dev
llvm-dev at lists.llvm.org
Fri Jul 1 08:18:36 PDT 2016
On 6/30/2016 5:20 PM, Robinson, Paul via cfe-dev wrote:
> We were using tags for a while in our own SVN->git conversion internally.
> (git branch is pushed to SVN and the SVN r-number used to create a tag.)
> They are convenient for some things, but each tag adds a new (if small)
> file to .git/tags and I don't know that it really scales well when you
> are talking about (long term) hundreds of thousands of them. That was
> not what tags were designed for.
We're using tags in this manner for our internal repos and LLVM/Clang
mirrors and haven't experienced any problems. We're at ~50k tags for
our most used repo, so not quite at hundreds of thousands yet.
When I look in .git/refs/tags of one of my repos, I do *not* see 50k
files; I see ~400. I'm not sure what causes some to appear here and
I don't see how this use of tags is not representative of what tags were
designed for. They are designed to label a commit. That seems to match
well what is desired here.
> We've since stopped creating the tags, and gotten used to not having
> them. We do the 'rev-list --count' trick which mainly gets recorded as
> one component of the version number, and it has been working for us.
As I understand it, 'git rev-list --count HEAD' requires walking the
entire commit history. Perhaps the performance is actually ok in
practice, but I would be concerned about scaling with this approach as well:
$ time git rev-list --count HEAD
> I think having the number in the commit log (even if it's just for the
> superproject) would be preferable. You can use 'git log --grep' to
> find a particular rev if you need to.
Grepping every commit doesn't seem like the most scalable option either.
I did a quick test on a large repo. First a grep for an identifier:
$ time git log --grep <id>
Then I did the same for the associated push tag:
$ time git log -n 1 <tag>
More information about the llvm-dev