[llvm-dev] [RFC] One or many git repositories?
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 25 13:55:47 PDT 2016
> On Jul 25, 2016, at 1:40 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> On 25 July 2016 at 17:54, Justin Lebar via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> To re-focus this thread on its original topic: It sounds to me like,
>> broadly speaking, we have consensus on using a single repository.
> In this thread, yes. :)
> Can you write up a document on docs/Proposals and add a review?
> I think the survey should be about both of them, and allow people to
> digress. I'm willing to take the time to read all of them and try to
> collate a "big-picture", but I'd appreciate if others could help me.
> I don't think we'll ever get *consensus* on any email thread, as
> people do digress too much.
>> 1) Should the repository have "unified history"? (Meaning, should I
>> be able to check out a single git revision from before the migration
>> and have it contain all of the llvm subprojects?)
> Every VCS migration I've been involved so far involved doing this, as
> it makes it much easier to deal with comparisons between new and old.
> Applying patches, trying benchmarks, etc. all become much easier if
> you use a single tool / source to checkout from.
>> 2) Should the monorepo have a "nested" repository layout (e.g. clang
>> goes in /tools/clang) or a "flat" layout (clang goes in /clang)?
> Slight preference to nested, but I don't mind either way.
> We internally checkout separate and create the worktrees as nested, so
> nested is slightly better for us.
>> 3) Assuming we want unified history, should the new canonical
>> repository's hashes be based on
>> https://github.com/llvm-project/llvm-project, or should it start
> Fresh, please.
> That one seems good, nested or not
To clarify: this repo especially is what happen when answering “No” to question 1) (you answered yes above), and is not “Fresh” as it is preserving hashes from previous repository.
(Leaving aside the nested part)
> , but I'm not sure about polly.
> Maybe OpenMP (like parallel-libs?).
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev