llvm dev - May 2016 - GitHub anyone?

Chris Lattner via llvm-dev wrote:
> Personally, I’m hugely in favor of moving llvm’s source hosting to github
at
> some point, despite the fact that I continue to dislike git as a tool and
> consider monotonicly increasing version numbers to be hugely beneficial.
For whatever it's worth, our projects define a `buildnum` git alias:

  alias.buildnum=!sh -c "git rev-list --all | wc -l"

So from the shell:

  $ git buildnum
  17475

This number increases monotonically per commit.


Our build scripts make this number available in various #define forms.

(We use a little extra scripting logic to also determine whether there
are currently any unmerged or uncommitted changes, and add an annotation
to the program version in that case, e.g.  "9.3.17475 [unmerged]")


It's all stupidly simple, but seems to work well enough for us.



Regards,

Bill

> On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Chris Lattner via llvm-dev wrote:
>> Personally, I’m hugely in favor of moving llvm’s source hosting to
github at
>> some point, despite the fact that I continue to dislike git as a tool
and
>> consider monotonicly increasing version numbers to be hugely
beneficial.
> 
> For whatever it's worth, our projects define a `buildnum` git alias:
> 
>  alias.buildnum=!sh -c "git rev-list --all | wc -l"
> 
> So from the shell:
> 
>  $ git buildnum
>  17475
> 
> This number increases monotonically per commit.
It does not work with branches though (we're not really planning to have
branches I believe), but more importantly it won't handle cross-repository
versioning (how do you relate the number this command prints in the llvm repo to
the number it'll print in the clang repo?), which I believe is something
important considering our setup.

-- 
Mehdi


> 
> 
> Our build scripts make this number available in various #define forms.
> 
> (We use a little extra scripting logic to also determine whether there
> are currently any unmerged or uncommitted changes, and add an annotation
> to the program version in that case, e.g.  "9.3.17475
[unmerged]")
> 
> 
> It's all stupidly simple, but seems to work well enough for us.
> 
> 
> 
> Regards,
> 
> Bill
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Mehdi
> Amini via llvm-dev
> Sent: Tuesday, May 31, 2016 2:38 PM
> To: Bill Kelly
> Cc: LLVM Dev; Clang Dev; LLDB Dev
> Subject: Re: [llvm-dev] GitHub anyone?
> 
> 
> > On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev <llvm-
> dev at lists.llvm.org> wrote:
> >
> > Chris Lattner via llvm-dev wrote:
> >> Personally, I’m hugely in favor of moving llvm’s source hosting to
> github at
> >> some point, despite the fact that I continue to dislike git as a
tool
> and
> >> consider monotonicly increasing version numbers to be hugely
> beneficial.
> >
> > For whatever it's worth, our projects define a `buildnum` git
alias:
> >
> >  alias.buildnum=!sh -c "git rev-list --all | wc -l"
Or the cheaper "git rev-list --count --all" if your git is new enough.
We do something like this as well.
> >
> > So from the shell:
> >
> >  $ git buildnum
> >  17475
> >
> > This number increases monotonically per commit.
> 
> It does not work with branches though (we're not really planning to
have
> branches I believe), 
You can get a per-branch unique number with this tactic.  On our local
branches we use "rev-list origin/master.." which is the number of
commits
since branching from master, and that's enough for our local purposes.
> but more importantly it won't handle cross-repository
> versioning (how do you relate the number this command prints in the llvm
> repo to the number it'll print in the clang repo?), which I believe is
> something important considering our setup.
Is it really that important?  Or are we just used to the convenience?
If the Clang build number is a tuple (cfe-number, llvm-number) instead
of a single number, how horrible is that really?  If you consider what
an out-of-tree front end probably does, it's exactly the same thing.

(I admit that locally we mush cfe+llvm into a single branch and do the
rev-list count to get a single number. But that's more for our own
convenience than anything else.)
--paulr
> 
> --
> Mehdi
> 
> 
> 
> >
> >
> > Our build scripts make this number available in various #define forms.
> >
> > (We use a little extra scripting logic to also determine whether there
> > are currently any unmerged or uncommitted changes, and add an
annotation
> > to the program version in that case, e.g.  "9.3.17475
[unmerged]")
> >
> >
> > It's all stupidly simple, but seems to work well enough for us.
> >
> >
> >
> > Regards,
> >
> > Bill
> >
> > _______________________________________________
> > 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