[lldb-dev] [llvm-dev] GitHub anyone?

[Robinson, Paul via lldb-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