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

On Thu, Jun 30, 2016 at 9:16 AM, James Y Knight via lldb-dev <
lldb-dev at lists.llvm.org> wrote:
> I don't think we should do any of that. It's too complicated -- and
I
> don't see the reason to even do it.
>
> There's a need for the "llvm-project" repository --
that's been discussed
> plenty -- but where does the need for a separate "id" that must
be pushed
> into all of the sub-projects come from? This is the first I've heard of
> that as a thing that needs to be done.
>
> There was a previous discussion about putting an sequential ID in the
> "llvm-project" repo commit messages (although, even that I'd
say is
> unnecessary), but not anywhere else.
>
Agreed, the llvm-project repository can completely take on the role of the
SQL database in Renato's proposal.

Chromium created a "git-number" extension that assigns sequential ids
to
commits in the obvious way, and that provided some continuity with the
"git-svn-id:" footers in commit messages. I'm not sure their
extension is
particularly reusable, though:
https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/master/git_number.py

I think for LLVM, whatever process updates the umbrella repo should add the
sequential IDs to the commit message, and that will help provide continuity
across the git/svn bridge.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160630/9a187661/attachment.html>

On 30 June 2016 at 17:33, Reid Kleckner <rnk at google.com>
wrote:
> Agreed, the llvm-project repository can completely take on the role of the
> SQL database in Renato's proposal.
Hum, doing it in a separate server was suggested by the GitHub folks,
so I just assumed they can't do that in the umbrella project for some
reason.

I'm all for using the umbrella if we can, I just though we couldn't...
:(

Can someone try the suggested tag style? Are we sure we can guarantee
atomicity in there? I know SQL can. :)

I know that changing the commit message works because of Gerrit and
our current SVN integration, I don't know how much adding one tag for
each push will work in Git over time.

cheers,
--renato

I assumed we want ids for the umbrella repository to ease bisection and having
something to print as a version identifier, but do we really need them for the
other repositories?

I also still don't see why `git rev-list --count --all` does not work. Sure
the count is only per branch, but why would ever need to have continuous
numbering between say a 3.8.XX revision and a 3.9.XX branch...

- Matthias
> On Jun 30, 2016, at 9:33 AM, Reid Kleckner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On Thu, Jun 30, 2016 at 9:16 AM, James Y Knight via lldb-dev <lldb-dev
at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
> I don't think we should do any of that. It's too complicated -- and
I don't see the reason to even do it.
> 
> There's a need for the "llvm-project" repository --
that's been discussed plenty -- but where does the need for a separate
"id" that must be pushed into all of the sub-projects come from? This
is the first I've heard of that as a thing that needs to be done.
> 
> There was a previous discussion about putting an sequential ID in the
"llvm-project" repo commit messages (although, even that I'd say
is unnecessary), but not anywhere else.
> 
> Agreed, the llvm-project repository can completely take on the role of the
SQL database in Renato's proposal.
> 
> Chromium created a "git-number" extension that assigns sequential
ids to commits in the obvious way, and that provided some continuity with the
"git-svn-id:" footers in commit messages. I'm not sure their
extension is particularly reusable, though:
>
https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/master/git_number.py
<https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/master/git_number.py>
> 
> I think for LLVM, whatever process updates the umbrella repo should add the
sequential IDs to the commit message, and that will help provide continuity
across the git/svn bridge.
> _______________________________________________
> 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/20160630/6e1c6ce6/attachment.html>

> -----Original Message-----
> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of
Renato
> Golin via cfe-dev
> Sent: Thursday, June 30, 2016 9:49 AM
> To: Reid Kleckner
> Cc: LLVM Dev; llvm-foundation at lists.llvm.org; Clang Dev; LLDB Dev
> Subject: Re: [cfe-dev] [lldb-dev] [llvm-dev] Sequential ID Git hook
> 
> On 30 June 2016 at 17:33, Reid Kleckner <rnk at google.com> wrote:
> > Agreed, the llvm-project repository can completely take on the role of
> the
> > SQL database in Renato's proposal.
> 
> Hum, doing it in a separate server was suggested by the GitHub folks,
> so I just assumed they can't do that in the umbrella project for some
> reason.
> 
> I'm all for using the umbrella if we can, I just though we
couldn't... :(
> 
> Can someone try the suggested tag style? Are we sure we can guarantee
> atomicity in there? I know SQL can. :)
> 
> I know that changing the commit message works because of Gerrit and
> our current SVN integration, I don't know how much adding one tag for
> each push will work in Git over time.
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'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.

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.
--paulr
> 
> cheers,
> --renato
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

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?

Enough people complained about the sequential number, and I'm trying to
solve that problem. I particularly have no use for that at all.

We can still do the bundling pushes with the same id by adding metadata to
the commit message and training our CI, which is orthogonal to this issue.

Cheers,
Renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160701/5b80b971/attachment.html>

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

From: Renato Golin [mailto:renato.golin at linaro.org] 
Sent: Thursday, June 30, 2016 4:15 PM
To: Robinson, Paul
Cc: Clang Dev; LLDB Dev; LLVM Dev; Reid Kleckner; llvm-foundation at
lists.llvm.org
Subject: RE: [cfe-dev] [lldb-dev] [llvm-dev] Sequential ID Git hook


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? 

I don't know, we don't use submodules, we use subtree merges to create
an omnibus branch.  If it *does* work in the parent project, that would
be cool (and might motivate us to reorganize our internal branches that
way, but not this year).
--paulr