[llvm-dev] [RFC] One or many git repositories?

[NAKAMURA Takumi via llvm-dev]

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
sub repository.
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
> afresh?
>

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
existing subproject.git.

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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160725/25f5a49a/attachment.html>