<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 20, 2016, at 5:46 PM, Chandler Carruth via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Jul 20, 2016 at 5:36 PM Justin Bogner <<a href="mailto:mail@justinbogner.com" class="">mail@justinbogner.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank" class="">chandlerc@google.com</a>> writes:<br class="">> On Wed, Jul 20, 2016 at 5:02 PM Justin Bogner via llvm-dev <<br class="">><span class="Apple-converted-space"> </span><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">><br class="">>> Justin Lebar via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> writes:<br class="">>> > I would like to (re-)open a discussion on the following specific<br class="">>> question:<br class="">>> ><br class="">>> > Assuming we are moving the llvm project to git, should we<br class="">>> > a) use multiple git repositories, linked together as subrepositories<br class="">>> > of an umbrella repo, or<br class="">>> > b) use a single git repository for most llvm subprojects.<br class="">>> ><br class="">>> > The current proposal assembled by Renato follows option (a), but I<br class="">>> > think option (b) will be significantly simpler and more effective.<br class="">>> > Moreover, I think the issues raised with option (b) are either<br class="">>> > incorrect or can be reasonably addressed.<br class="">>> ><br class="">>> > Specifically, my proposal is that all LLVM subprojects that are<br class="">>> > "version-locked" (and/or use the common CMake build system) live in a<br class="">>> > single git repository. That probably means all of the main llvm<br class="">>> > subprojects other than the test-suite and maybe libc++. From looking<br class="">>> > at the repository today that would be: llvm, clang, clang-tools-extra,<br class="">>> > lld, polly, lldb, llgo, compiler-rt, openmp, and parallel-libs.<br class="">>><br class="">>> FWIW, I'm opposed. I'm not convinced that the problems with multiple<br class="">>> repos are any worse than the problems with a single repo, which makes<br class="">>> this more or less just change for the sake of change, IMO.<br class="">>><br class="">><br class="">> It would be useful to know what problems you see with a single repo that<br class="">> are more significant. In particular, either why you think the problems<br class="">> jlebar already mentioned are worse than he sees them, or what other<br class="">> problems are that he hasn't addressed.<br class=""><br class="">Running the same 'git checkout' commands on multiple repos has always<br class="">been sufficient to manage the multiple repos so far - as long as you<br class="">create the same branches and tags in each repo, it's easy[1] to manage<br class="">the set of repos with a script that cd's to each one and runs whatever<br class="">git command.<br class=""></blockquote><div class=""><br class=""></div><div class="">A notable difference is the ability to do API updates across them or the ability to bisect across them.</div><div class=""><br class=""></div><div class="">Also, if the infrastructure that keeps the umbrella repo in sync falls over or has a serious problem, reconstructing version-locked state in order to bisect across those regions of time seems quite challenging. So IMO, it isn't a minor inconvenience, even if it is something we could overcome.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">So it's a pretty minor inconvenience today to have the multiple repos in<br class="">the case where you want to check out all of them.<br class=""><br class="">OTOH, if all of the repos are combined into one, you have to do work<br class="">when you only want some of them. In my experience, this is basically<br class="">always - between my various machines and projects I have a several<br class="">checkouts of llvm+compiler-rt+clang+libc++, and I have a lot of<br class="">checkouts of just llvm. I've only checked out the other repos when I was<br class="">changing APIs and needed to update them.<br class=""><br class="">I haven't tried the options jlebar has described to deal with these -<br class="">sparse checkouts and whatnot, but they seem like an equivalent amount of<br class="">work/learning curve as writing a script that cd's to several directories<br class="">and runs the same git command in each.<br class=""></blockquote><div class=""><br class=""></div><div class="">I actually would like to see an example of how you would checkout a common subset with the sparse checkout feature. jlebar, could you give us demo commands for this?</div></div></div></div></blockquote><div><br class=""></div><div>Since there is already a unified repo for testing here: <a href="https://github.com/llvm-project/llvm-project" class="">https://github.com/llvm-project/llvm-project</a></div><div><br class=""></div><div>Here is what it would look like for someone interested in checking out in LLVM and Clang only:</div><div><br class=""></div><div># Prepare the git repo</div><div>mkdir llvm</div><div>cd llvm</div><div>git init</div>git remote add origin <a href="mailto:git@github.com" class="">git@github.com</a>:llvm-project/llvm-project.git</div><div><br class=""></div><div># Setup the sparse checkout, asking for clang and llvm only<br class=""><div>git config core.sparseCheckout true</div><div>mkdir .git/info</div><div>echo /llvm >> .git/info/sparse-checkout </div><div>echo /clang >> .git/info/sparse-checkout </div><div><br class=""></div><div># Actually fetch the data and checkout just clang and llvm.</div><div>git pull origin master</div><div><br class=""></div><div># At this point the checkout contains the directories for clang and llvm only.</div><div><br class=""></div><div>Obviously this will download the 2.5GB repository (all branches for all projects), but that should happen *once* on a developer machine (future clone can be using `git worktree`).</div><div>For bots, shallow clone are efficient, with some modification to the script above:</div><div><br class=""></div><div><div><div># Prepare the git repo</div><div>mkdir llvm</div><div>cd llvm</div><div>git init</div>git remote add origin <a href="mailto:git@github.com" class="">git@github.com</a>:llvm-project/llvm-project.git -t master</div><div><br class=""></div><div># Setup the sparse checkout, asking for clang and llvm only<br class=""><div>git config core.sparseCheckout true</div><div>mkdir .git/info</div><div>echo /llvm >> .git/info/sparse-checkout </div><div>echo /clang >> .git/info/sparse-checkout </div><div><br class=""></div><div># Actually fetch the data and checkout just clang and llvm.</div><div>git pull origin master --depth=1</div><div># alternatively: git fetch —depth=1 && git reset —hard origin/master<br class=""><br class=""></div><div>(That’s 81.58MB download, independently of the number of sub-projects to actually checkout)</div><div class=""><br class=""></div></div></div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div></div></body></html>