> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-boun...@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- > d...@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-...@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
