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

> On Jun 30, 2016, at 4:14 PM, Renato Golin via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> On 30 Jun 2016 10:20 p.m., "Robinson, Paul" <paul.robinson at
sony.com <mailto:paul.robinson at sony.com>> wrote:
> > 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.
> 
> Does that work for sub modules inside the umbrella project?
> 
> How can you trigger a hook in the umbrella project for commits inside the
sub modules?
> 
First: This is purely about generating sequential revision numbers, it does not
help setting up a server hook to update the submodule references in the meta
repository. The point I am trying to make here is that we only need to solve the
problem of updating the submodule references, and that generating sequential ID
numbers as an alternative to git hashes is no problem.

As far as I can see we need the following operations for sequential ID numbers
and they are all easy enough to perform with git on the client side:

1. Produce revision number for current checkout (to use in tool --version
output):
You can put something like
  > echo "#define VERSION $(git rev-list --count HEAD)" >
version.h
in your buildsystem

2. Convert git hash to revision number:
  git rev-list --count $HASH

3. Convert revision number $NUM to git hash:
  git rev-list HEAD | tail -n $NUM | head -n 1

- Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160630/9b08b4e0/attachment.html>

> El jun. 30, 2016, a las 19:31, Matthias Braun via cfe-dev <cfe-dev at
lists.llvm.org> escribió:
> 
> 
>> On Jun 30, 2016, at 4:14 PM, Renato Golin via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> 
>> On 30 Jun 2016 10:20 p.m., "Robinson, Paul" <paul.robinson
at sony.com <mailto:paul.robinson at sony.com>> wrote:
>> > 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.
>> 
>> Does that work for sub modules inside the umbrella project?
>> 
>> How can you trigger a hook in the umbrella project for commits inside
the sub modules?
>> 
> First: This is purely about generating sequential revision numbers, it does
not help setting up a server hook to update the submodule references in the meta
repository. The point I am trying to make here is that we only need to solve the
problem of updating the submodule references, and that generating sequential ID
numbers as an alternative to git hashes is no problem.
> 
> As far as I can see we need the following operations for sequential ID
numbers and they are all easy enough to perform with git on the client side:
> 
> 1. Produce revision number for current checkout (to use in tool --version
output):
> You can put something like
>   > echo "#define VERSION $(git rev-list --count HEAD)" >
version.h
> in your buildsystem
> 
> 2. Convert git hash to revision number:
>   git rev-list --count $HASH
> 
> 3. Convert revision number $NUM to git hash:
>   git rev-list HEAD | tail -n $NUM | head -n 1
I just want to point out another alternative that I often use in my projects: 
(Example from buildbot repo I had handy)

$ git describe
v0.9.0b8-579-ge06cac6

The format is "TAG-N-gREV", where TAG is the closest reachable git tag
in the past ("v0.9.0b8"), N is the relative number of revisions past
that tag (579), and REV is the short revision to make it unique and easy to
locate ("e06cac6", the 'g' is a literal character that
prefixes the revision). In other words, that "-579-" represents a
monotonically increasing value relative to the named tag and might serve your
purposes.

Jared

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160703/8917b170/attachment.html>

"git-describe -t" works also for lw tags.

2016年7月4日(月) 2:48 Jared Grubb via cfe-dev <cfe-dev at lists.llvm.org>:
>
> El jun. 30, 2016, a las 19:31, Matthias Braun via cfe-dev <
> cfe-dev at lists.llvm.org> escribió:
>
>
> On Jun 30, 2016, at 4:14 PM, Renato Golin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
> On 30 Jun 2016 10:20 p.m., "Robinson, Paul" <paul.robinson at
sony.com>
> wrote:
> > 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.
>
> Does that work for sub modules inside the umbrella project?
>
> How can you trigger a hook in the umbrella project for commits inside the
> sub modules?
>
> First: This is purely about generating sequential revision numbers, it
> does not help setting up a server hook to update the submodule references
> in the meta repository. The point I am trying to make here is that we only
> need to solve the problem of updating the submodule references, and that
> generating sequential ID numbers as an alternative to git hashes is no
> problem.
>
> As far as I can see we need the following operations for sequential ID
> numbers and they are all easy enough to perform with git on the client
side:
>
> 1. Produce revision number for current checkout (to use in tool --version
> output):
> You can put something like
>   > echo "#define VERSION $(git rev-list --count HEAD)" >
version.h
> in your buildsystem
>
> 2. Convert git hash to revision number:
>   git rev-list --count $HASH
>
> 3. Convert revision number $NUM to git hash:
>   git rev-list HEAD | tail -n $NUM | head -n 1
>
>
> I just want to point out another alternative that I often use in my
> projects:  (Example from buildbot repo I had handy)
>
> $ git describe
> v0.9.0b8-579-ge06cac6
>
> The format is "TAG-N-gREV", where TAG is the closest reachable
git tag in
> the past ("v0.9.0b8"), N is the relative number of revisions past
that tag
> (579), and REV is the short revision to make it unique and easy to locate
> ("e06cac6", the 'g' is a literal character that prefixes
the revision). In
> other words, that "-579-" represents a monotonically increasing
value
> relative to the named tag and might serve your purposes.
>
> Jared
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160704/3e200371/attachment-0001.html>