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

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

On 4 Jul 2016, at 12:13, Renato Golin via llvm-foundation <llvm-foundation at
lists.llvm.org> wrote:
> 
> 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?
One of the nice features of GitHub is that it provides a download link to grab
tarballs for any specific version.  These are easy to se with other workflows
(for example, the FreeBSD ports collection has infrastructure for grabbing a
release and building it).  It would be a shame if you needed a full git clone to
get the revision information, as that would mean that anyone who built from a
tarball would lose it.

David

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/llvm-dev/attachments/20160705/fbe033fd/attachment.html>

On 4 July 2016 at 15:21, Bruce Hoult <bruce at hoult.org>
wrote:
> What doesn't scale about tagging every commit?
Both Jim and Takumi have reported problems with thousands of tags.
Even though neither of them responded to your enquiries for additional
data, we can't assume there isn't any.

Furthermore, "git describe" seems to be the "mixed mode" I
asked
about, and it's already in git since an old version, so I'm not sure
why we'd even need to create one tag per commit anyway.

People should be using Git for bisects, in which case it works out of
the box. The incremental version was mostly to tag the build with
something meaningful, which "git describe" is.

Even if you want to use the result of describe to bisect like SVN, it
works because our history is linear (and you can count the number of
commits between A and B, and even store a local list of the hashes in
between.

I really can't see why would we need to tag every commit.

cheers,
--renato

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.

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, ...


On Mon, Jul 4, 2016 at 11:51 PM, Bruce Hoult via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>>
>
>
> _______________________________________________
> 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/llvm-dev/attachments/20160705/96e5da66/attachment.html>