[lldb-dev] [llvm-dev] [cfe-dev] Sequential ID Git hook

[Bruce Hoult via lldb-dev]

What doesn't scale about tagging every commit?

True, every tag creates a small file on disk, but then so does every commit.

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.

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.

On Mon, Jul 4, 2016 at 11:13 PM, Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On 4 July 2016 at 06:01, NAKAMURA Takumi via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > "git-describe -t" works also for lw tags.
>
> But it doesn't work if there are no tags, I just tested on LLVM and I get:
>
> $ git describe
> fatal: No names found, cannot describe anything.
>
> Should be easy enough to create the tags on each branching point, though.
>
> "describe" also seems to be available at least since Git 1.9, so it
> should be pretty safe.
>
> And since tagging *every* commit doesn't scale for long ranges, and
> anything else will need scripting on the client side, I think we can
> get rid *completely* of any server side hook, and let the client side
> scripts deal with the output of "git describe".
>
> Or am I just too optimistic?
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160705/fbe033fd/attachment-0001.html>