<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 7, 2016, at 10:30 AM, <a href="mailto:dag@cray.com" class="">dag@cray.com</a> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Mehdi Amini via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> writes:<br class=""><br class=""><blockquote type="cite" class="">Right, we actually have a proposal to take what is in the current SVN<br class="">repo here: <a href="http://llvm.org/svn/llvm-project/" class="">http://llvm.org/svn/llvm-project/</a> and migrate this to a<br class="">single repository.<br class="">I was not sure if you were referring to this proposal (monorepo) or to<br class="">the recent emails about “external libraries” that GCC uses like gmp<br class="">and mpfr. <br class=""><br class="">You can find more details here: <a href="https://reviews.llvm.org/D24167" class="">https://reviews.llvm.org/D24167</a><br class=""><br class="">If you have some good reasons why you would think a proposal would be<br class="">problematic to you, or one would better fit your workflow, feel free<br class="">to expose them now.<br class=""></blockquote><br class="">It could be problematic for us depending on how the monorepository is<br class="">structured. We reference the LLVM git repository directly and use it to<br class="">migrate to new versions, pick patches, etc. If LLVM proper were part of<br class="">a larger repository that becomes more difficult to do because the commit<br class="">file paths won't match. We'd be back to essentially manual diff+patch<br class="">which is quite a step backward from the smoth git-oriented process we<br class="">use now.<br class=""></div></div></blockquote><div><br class=""></div><div>Can you clarify what you mean? Which part of the process would quite manual patch that wouldn’t otherwise?</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">The document says that the individual git repositories will remain.<br class="">Does that mean the monorepository is using git-submodule to manage the<br class="">aggregate repository? </div></div></blockquote><div><br class=""></div><div>First, have you read this document: <a href="https://reviews.llvm.org/D24167" class="">https://reviews.llvm.org/D24167</a> ?</div><div><br class=""></div><div>TLDR: The answer is no: you have to see it as it is today, i.e. a single SVN repo containing all the sub-projects, and “exports” in individual repositories.</div><div>The same thing after: a single git repo containing all the subprojects side-by-side and the *same* “exports” in individual repositories.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> If so that should work for us. I'm more<br class="">concerned about the case where the individual repositories' histories<br class="">were interwoven into a single repository and the individual repositories<br class="">went away.<br class=""><br class="">I have extensive experience transitioning a very large project from a<br class="">set of individual repositories to a single repository where we interwove<br class="">the individual histories. It was the right direction for us but I don't<br class="">think it would be for LLVM.<br class=""><br class="">I completely understand the benefits of a monorepository. One of the<br class="">biggest for us was the ability to git-bisect across components. How<br class="">does git-bisect work with submodules? I have very little experience<br class="">with submodules but would like to learn more.<br class=""></div></div></blockquote><div><br class=""></div><div>Fairly easy, the document mentions it in the examples.</div><div><br class=""></div></div><br class=""></div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div></body></html>