> -----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
> On May 31, 2016, at 3:38 PM, Robinson, Paul <paul.robinson at sony.com> wrote: > > > >> -----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?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-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
> -----Original Message----- > From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] > Sent: Tuesday, May 31, 2016 3:54 PM > To: Robinson, Paul > Cc: Bill Kelly; Clang Dev; LLDB Dev; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] GitHub anyone? > > > > On May 31, 2016, at 3:38 PM, Robinson, Paul <paul.robinson at sony.com> > wrote: > > > > > > > >> -----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? > > 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)I know that on a single branch, "git bisect" deals with that for you. I've seen the talk about submodules but I have no clue how that works or whether git-bisect can operate cleanly in that situation. --paulr> > -- > 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-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