<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jul 25, 2016 at 9: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">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></blockquote><div><br></div><div>I strongly agree about this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) Yes to nested layout.  I find Chandler and Richard Smith's<br>
arguments compelling.<br></blockquote><div><br></div><div>I think it is important to note what Richard pointed out: *we will almost certainly restructure the tree to make more sense in a monorepo*.</div><div><br></div><div>I think the result is actually very likely to look much more flat than the current layout, and to also be significantly superior to any of the current layouts.</div><div><br></div><div>I just don't want people to think this locks us into a particular nested layout for all time.</div></div></div>