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

Wed Jun 1 04:17:09 PDT 2016

With submodules, the current hash of each submodule is recorded in each
master commit. If you check out a different master repository commit then
you run 'git submodule update' and it checks out the corresponding commit
in each submodule. I'm not sure why this isn't automatic with the master
repo commit checkout, but in any case it's not difficult.

So when you do a git bisect, you just need to make sure there is a 'git
submodule update' at the start of your bisect script.

It will be fun to get all the correct hashes recorded in the master repo
during initial import. But not all that difficult: check out next svn
revision; check and push in any submodules with changes in that revision;
then commit the master repo for that revision.

On Wed, Jun 1, 2016 at 2:06 AM, Robinson, Paul via llvm-dev <
llvm-dev at lists.llvm.org> 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.
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160601/94309045/attachment-0001.html>