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

[Rafael Espíndola via lldb-dev]

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
On Jun 27, 2016 11:10 AM, "Renato Golin" <renato.golin at linaro.org> wrote:

> On 27 June 2016 at 15:39, Rafael Espíndola <rafael.espindola at gmail.com>
> 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 the order of inclusion (llvm
> into clang), but to *not* change anything else at this stage.
>
> That's one of the reasons the umbrella project with sub-modules was
> the most accepted solution, because we can later change the inclusion
> order (if we all agree, etc), without changing the underlying storage.
>
>
> > * Change llvm.
> > * Change clang and in the same atomic commit change what revision the
> > submodule points to.
>
> Having one repository inside another was rejected due to the problems
> it brings for development, validation and release. James has just
> pointed a few of those problems for development.
>
> An umbrella project with a commit hook and an auto-update would make
> sure all commits are synchronised correctly. Though, indeed, this will
> mean we'll still have the trouble of buildbots picking up one commit
> and not the other, I don't think this is a big enough problem that we
> should mess up everyone's workflow.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160627/f9cc868e/attachment.html>