[llvm-dev] GitHub anyone?

[Mehdi Amini via llvm-dev]

> On May 31, 2016, at 4:06 PM, Robinson, Paul <paul.robinson at sony.com> wrote:
> 
> 
> 
>> -----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.

Sure, but our case is worse than branches: it is *cross repositories rev-locks".

> 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.

Submodules is one solution, I gave some other pointers in this thread previously.

-- 
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