[llvm-dev] [RFC] One or many git repositories?
NAKAMURA Takumi via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 25 10:34:21 PDT 2016
On Tue, Jul 26, 2016 at 1:54 AM 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. But
> there are still some outstanding related questions. Among these are:
> 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?)
Yes, I suggest we may provide the unified tree, as an option.
I don't agree for us to move to the unified tree.
2) Should the monorepo have a "nested" repository layout (e.g. clang
> goes in /tools/clang) or a "flat" layout (clang goes in /clang)?
No, I prefer a flat tree.
That said, I don't object if anyone released a nested tree.
Regarding to technical reason, the flat tree contains root trees in each
For example, both llvm.git and llvm-project(tree).git have the
tree 9697e220d778081eef8d0c507dea35b53042ea9e .
I suppose the nested layout may be by historical reason.
(IMO, clang and other subprojects might be moved to projects from tools)
> 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
Yes and no.
In past, I rebased the tree when I add new projects.
I still wonder what I could do when I add/remove projects.
I'd like to add some projects in near future.
I could remove dragonegg and klee. But I think the tree may contain all
FWIW my answers to these are:
> 1) Yes to unified history. The main advantage of non-unified history
> is that it's easier for people to import old branches -- it's a matter
> of "git merge" instead of running the git filter-branch script I
> wrote. But this is a relatively small (~20 minute) one-time cost to
> some of us, whereas our repository history is born by all of us
> forever. Moreover unified history also helps people with long-running
> branches, as it lets them check out old versions of their branch and
> get a compatible version of all of the other llvm subprojects.
> 2) Yes to nested layout. I find Chandler and Richard Smith's
> arguments compelling.
> 3) No to basing the new canonical repo on
> https://github.com/llvm-project/llvm-project. That repo's history is
> missing svn revision numbers, and there are enough emails floating
> around that reference svn revision numbers that I think we need them
> in our canonical repo. Also llvm-project/llvm-project has a flat
> structure, and if we end up going with a nested layout, it would be
> better to have that layout starting with the first commit.
It has refs/notes/commits.
fetch = +refs/notes/commits:refs/notes/commits
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev