> On May 31, 2016, at 3:38 PM, Robinson, Paul <paul.robin...@sony.com> wrote: > > > >> -----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?
I don't know how important it is. How would you bisect without this "convenience" for instance? (There is nothing like "push date" in git) -- Mehdi > 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
