[PATCH] D24167: Moving to GitHub - Unified Proposal

[Chris Bieneman via llvm-commits]

beanz added a comment.

I'll work up some suggested alternate phrases this weekend or early next week, but I have some responses inline.


================
Comment at: docs/Proposals/GitHubMove.rst:204
@@ +203,3 @@
+as we wish and preserve history.
+With the multirepo, moving clang-tools-extra into clang would be
+more complicated than a simple `git mv` command, and we would end up losing
----------------
Google is our friend -> http://stackoverflow.com/questions/1365541/how-to-move-files-from-one-git-repo-to-another-not-a-clone-preserving-history

================
Comment at: docs/Proposals/GitHubMove.rst:210
@@ +209,3 @@
+for downstream users that have interest in only a single repository, however
+this is addressed by keeping the single-subproject Git mirrors for each project just as we
+do today. Also the GitHub SVN bridge allows to contribute to a single
----------------
I don't think that our proposals should be constructed as convoluted arguments between contributing authors. Adding pro multi-repo statements will only make this more difficult to grok.

I actually think there is very little in this section that shouldn't be part of an "arguments/rebuttals" section.

================
Comment at: docs/Proposals/GitHubMove.rst:572
@@ +571,3 @@
+
+When the `git bisect run` command returns, the umbrella repository is set to
+the state where the regression is introduced, one can inspect the history on
----------------
You can absolutely *guarantee* the same granularity. You can't guarantee the same ordering, but generally speaking that is significantly less important than granularity.

To get the same granularity you allow the script that updates submodules to produce more than one commit to the submodule repo at a time. If there are multiple you can sort them by committer date. While committer date isn't a great thing to use since our proposals both depend on maintaining a linear history it should be good enough for the common cases because committer date gets reset on rebase. 

================
Comment at: docs/Proposals/GitHubMove.rst:629
@@ +628,3 @@
+only the projects that are *rev-locked* to LLVM (clang, lld, lldb, ...) and
+leave projects like libcxx and compiler-rt in their own individual and separate
+repositories.
----------------
Ah. I think the confusing phrasing is that monorepo is being used in two contexts. Maybe rephrase this to something like:

> With this variant of the monorepo proposal developers who only work on excluded sub-projects will continue to use the single-project repositories.

The workflow is still changed from today, because today we're using SVN.


================
Comment at: docs/Proposals/GitHubMove.rst:637
@@ +636,3 @@
+
+Previews
+========
----------------
I'd like to see that mentioned here as well. This document is quite large and people may jump around reading it. It is worth having the note directly next to the link.


https://reviews.llvm.org/D24167