<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jul 26, 2016 at 1:54 AM Justin Lebar via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To re-focus this thread on its original topic: It sounds to me like,<br>
broadly speaking, we have consensus on using a single repository.  But<br>
there are still some outstanding related questions.  Among these are:<br>
<br>
1) Should the repository have "unified history"?  (Meaning, should I<br>
be able to check out a single git revision from before the migration<br>
and have it contain all of the llvm subprojects?)<br></blockquote><div><br></div><div>Yes, I suggest we may provide the unified tree, as an option.</div><div>I don't agree for us to move to the unified tree.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2) Should the monorepo have a "nested" repository layout (e.g. clang<br>
goes in /tools/clang) or a "flat" layout (clang goes in /clang)?<br></blockquote><div><br></div><div>No, I prefer a flat tree.</div><div>That said, I don't object if anyone released a nested tree.</div><div><br></div><div>Regarding to technical reason, the flat tree contains root trees in each sub repository.</div><div>For example, both llvm.git and llvm-project(tree).git have the tree 9697e220d778081eef8d0c507dea35b53042ea9e .</div><div><br></div><div>I suppose the nested layout may be by historical reason.</div><div><span style="line-height:1.5">(IMO, clang and other subprojects might be moved to projects from tools)</span></div><div><span style="line-height:1.5"> </span><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) Assuming we want unified history, should the new canonical<br>
repository's hashes be based on<br>
<a href="https://github.com/llvm-project/llvm-project" rel="noreferrer" target="_blank">https://github.com/llvm-project/llvm-project</a>, or should it start<br>
afresh?<br></blockquote><div><br></div><div>Yes and no.</div><div>In past, I rebased the tree when I add new projects.</div><div><br></div><div>I still wonder what I could do when I add/remove projects.</div><div>I'd like to add some projects in near future.</div><div>.</div><div>I could remove dragonegg and klee. But I think the tree may contain all existing subproject.git.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
FWIW my answers to these are:<br>
<br>
1) Yes to unified history.  The main advantage of non-unified history<br>
is that it's easier for people to import old branches -- it's a matter<br>
of "git merge" instead of running the git filter-branch script I<br>
wrote.  But this is a relatively small (~20 minute) one-time cost to<br>
some of us, whereas our repository history is born by all of us<br>
forever.  Moreover unified history also helps people with long-running<br>
branches, as it lets them check out old versions of their branch and<br>
get a compatible version of all of the other llvm subprojects.<br>
<br>
2) Yes to nested layout.  I find Chandler and Richard Smith's<br>
arguments compelling.<br>
<br>
3) No to basing the new canonical repo on<br>
<a href="https://github.com/llvm-project/llvm-project" rel="noreferrer" target="_blank">https://github.com/llvm-project/llvm-project</a>.  That repo's history is<br>
missing svn revision numbers, and there are enough emails floating<br>
around that reference svn revision numbers that I think we need them<br>
in our canonical repo.  Also llvm-project/llvm-project has a flat<br>
structure, and if we end up going with a nested layout, it would be<br>
better to have that layout starting with the first commit.<br></blockquote><div><br></div><div>It has refs/notes/commits.</div><div><br></div><div>  fetch = +refs/notes/commits:refs/notes/commits<br></div></div></div>