<div dir="ltr"><div><div>Very few operations search for commit objects by reading every single commit file. Most operations that read commit objects already know what they are looking for based on their hash. Plus, over time commit objects are packed into well indexed archive files, so the total number of commits stored in the filesystem never becomes an issue.<br><br>On the other hand, there are many commonly used git commands that might load and parse the entire set of references in order to function. git describe, git log (--decorate|--all), git fetch, git push, ...<br></div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 4, 2016 at 11:51 PM, Bruce Hoult via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What doesn't scale about tagging every commit?<div><br></div><div>True, every tag creates a small file on disk, but then so does every commit.</div><div><br></div><div>If you're worried about lots of files in a directory then you can put tags in nested directories by putting one or more /'s in the tag name. So you can hide all the commit tags in, say .git/refs/tags/commits and put release tags in the root tags directory, or another subdirectory. i.e. "git tag commit/23456 HEAD". Things such as shell command autocomplete (e.g. git checkout) deal intelligently with the tags directory structure, so you're not overwhelmed by 10000 commit tags when you just want to see the 40 release tags.</div><div><br></div><div>Also the files are only a short term thing anyway. When a "git gc" or "git pack" happens, tags get added to the compressed pack file just the same as objects do and the .git/refs/tags directory is cleared out.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 4, 2016 at 11:13 PM, Renato Golin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 4 July 2016 at 06:01, NAKAMURA Takumi via llvm-dev<br>
<span><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> "git-describe -t" works also for lw tags.<br>
<br>
</span>But it doesn't work if there are no tags, I just tested on LLVM and I get:<br>
<br>
$ git describe<br>
fatal: No names found, cannot describe anything.<br>
<br>
Should be easy enough to create the tags on each branching point, though.<br>
<br>
"describe" also seems to be available at least since Git 1.9, so it<br>
should be pretty safe.<br>
<br>
And since tagging *every* commit doesn't scale for long ranges, and<br>
anything else will need scripting on the client side, I think we can<br>
get rid *completely* of any server side hook, and let the client side<br>
scripts deal with the output of "git describe".<br>
<br>
Or am I just too optimistic?<br>
<br>
cheers,<br>
--renato<br>
<div><div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>