Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On 30 June 2016 at 05:14, Tim Northover wrote: >> That makes it fragile, and that’s why I disagree with your “90% done” >> assessment. >> What if the service behing the hook is down for a few days? > > In the long-term view, a pretty trivial catch-up script ought to be > able to synthesize a sane

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

> That makes it fragile, and that’s why I disagree with your “90% done” > assessment. > What if the service behing the hook is down for a few days? In the long-term view, a pretty trivial catch-up script ought to be able to synthesize a sane history after any amount of down-time. People could eve

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

> On Jun 29, 2016, at 10:03 AM, Renato Golin via llvm-dev > wrote: > > Hi all, > > A short summary: Takumi has done 90% of the work here: > > https://github.com/llvm-project/llvm-project-submodule > > and I've been talking to GitHub, and here are the answers to my questions: > > >> 1. How

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On Wed, Jun 29, 2016 at 12:34 PM, Sean Silva wrote: > > > On Wed, Jun 29, 2016 at 12:18 PM, Renato Golin > wrote: > >> On 29 June 2016 at 20:14, Sean Silva wrote: >> > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly >> > important special case we may be able to agree on

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On Wed, Jun 29, 2016 at 12:18 PM, Renato Golin wrote: > On 29 June 2016 at 20:14, Sean Silva wrote: > > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly > > important special case we may be able to agree on. (and I say this as > > somebody that largely builds cross-compil

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On 29 June 2016 at 20:14, Sean Silva wrote: > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly > important special case we may be able to agree on. (and I say this as > somebody that largely builds cross-compilers (targeting PS4)) In that case, RT wouldn't "have" to be cor

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On Wed, Jun 29, 2016 at 12:04 PM, Renato Golin wrote: > On 29 June 2016 at 19:51, Sean Silva wrote: > > Roughly speaking, I would prefer a repo division (if any) to be along the > > lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra > stuff > > not strictly required". > > The p

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On 29 June 2016 at 19:51, Sean Silva wrote: > Roughly speaking, I would prefer a repo division (if any) to be along the > lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra stuff > not strictly required". The problem comes when different people consider "core" different projects

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On 29 June 2016 at 15:11, David Chisnall wrote: > Will existing clones from the LLVM git mirror and / or llvm-mirror on GitHub > continue to work by simply switching the remote in the config? I hope so. There isn't anything (modulo mistakes) stopping us from having a clean migration. We'll have

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On Wed, Jun 29, 2016 at 9:28 AM, James Y Knight via llvm-dev < llvm-...@lists.llvm.org> wrote: > On Mon, Jun 27, 2016 at 12:13 PM, Renato Golin via llvm-dev < > llvm-...@lists.llvm.org> wrote: > >> On 27 June 2016 at 17:03, Rafael Espíndola >> wrote: >> > I think that trying to create a ordering/

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On Mon, Jun 27, 2016 at 12:13 PM, Renato Golin via llvm-dev < llvm-...@lists.llvm.org> wrote: > On 27 June 2016 at 17:03, Rafael Espíndola > wrote: > > I think that trying to create a ordering/rev number between independent > git > > repositories is fundamentally unreliable. > > > > If we want to

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On 29 Jun 2016, at 15:03, Renato Golin via llvm-dev wrote: > > Any more comments before we put this proposal to vote? Thank you very much for driving all of this. I just have one quick question: Will existing clones from the LLVM git mirror and / or llvm-mirror on GitHub continue to work by

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On 28 June 2016 at 16:46, Mehdi Amini wrote: > Why? Assuming we don’t have branches, there was many mention that the id can > be computed from the number of commits in the history. We have branches (release_nm) and we may want them to be in the same sequential numbering. So, I'm assuming this h

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

> On Jun 28, 2016, at 1:55 AM, NAKAMURA Takumi via llvm-dev > wrote: > > It has also submodules. > https://github.com/llvm-project/llvm-project-submodule > > > Both llvm-project(-tree) and (-submodule) have refs/notes/commits. This is

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

> On Jun 28, 2016, at 5:21 AM, Renato Golin via llvm-dev > wrote: > > On 28 June 2016 at 06:55, NAKAMURA Takumi wrote: >> It has also submodules. >> https://github.com/llvm-project/llvm-project-submodule >> >> Both llvm-project(-tree) and (-submodule) have refs/notes/commits. > > Nice! Can y

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On 28 June 2016 at 06:55, NAKAMURA Takumi wrote: > It has also submodules. > https://github.com/llvm-project/llvm-project-submodule > > Both llvm-project(-tree) and (-submodule) have refs/notes/commits. Nice! Can you try a server hook that will add an auto-increment number from submodules commits

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

It has also submodules. https://github.com/llvm-project/llvm-project-submodule Both llvm-project(-tree) and (-submodule) have refs/notes/commits. On Tue, Jun 28, 2016 at 1:13 AM Renato Golin via llvm-dev < llvm-...@lists.llvm.org> wrote: > On 27 June 2016 at 17:03, Rafael Espíndola > wrote: > >

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On 27 June 2016 at 17:03, Rafael Espíndola wrote: > I think that trying to create a ordering/rev number between independent git > repositories is fundamentally unreliable. > > If we want to keep llvm and clang in lock step we should probably probably > just have them in the same repository like >

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

Hello there, Renato, thank you for putting everything together. Talking about second question (commits mailing list): github provides set of various web hooks. I think here we are interested In 'push'es particularly. Besides that it has some CI related integrations: buildbots can update pull req

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

I think that trying to create a ordering/rev number between independent git repositories is fundamentally unreliable. If we want to keep llvm and clang in lock step we should probably probably just have them in the same repository like https://github.com/llvm-project/llvm-project. Cheers, Rafael

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On 27 June 2016 at 15:39, Rafael Espíndola wrote: > So, I probably missed something, but what was the main objection to > just using submodules? This would put llvm inside clang instead of the > other way around. When changing an API one currently has to I don't think the consensus was to change

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

>> As for updating the meta repository: We could disable write access for the >> normal llvm developer and delegate the submodule bumping to an external >> server. I believe this would be an easy enough job for buildbot or jenkins. > > The plan is to disable all write access to this repository (ot

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On 27 June 2016 at 01:20, Matthias Braun wrote: > I really liked the the solution proposed earlier in this thread: Do nothing > server side, but instead use > `git rev-list --count master` on the client side (which takes 0.9s on my > machine) to get the number of the commit. So nothing to do on

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

I really liked the the solution proposed earlier in this thread: Do nothing server side, but instead use `git rev-list --count master` on the client side (which takes 0.9s on my machine) to get the number of the commit. So nothing to do on the ID part IMO. As for updating the meta repository: We

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

On 26 June 2016 at 23:02, Anton Korobeynikov wrote: > Does github allow this? IIRC their support for server-side hooks was > very limited due to obvious reasons. And executing hooks e.g. on > llvm.org seems very error-prone. Someone suggested it was possible. I have sent them an email with a draf

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

> 1. Control the history via server hooks updating a unique and > auto-increment identifier, which will apply to every commit on its > submodules (ie, every other LLVM project). Does github allow this? IIRC their support for server-side hooks was very limited due to obvious reasons. And executing