[PATCH] D24167: Moving to GitHub - Unified Proposal

[Mehdi AMINI via llvm-commits]

mehdi_amini added inline comments.

================
Comment at: docs/Proposals/GitHubMove.rst:138
@@ +137,3 @@
+Git.
+
+What About Branches and Merges?
----------------
I'm not against mentioning this somewhere, but the "traditional" Git approach of hashes does not address at all the concerns mentioned right above.

================
Comment at: docs/Proposals/GitHubMove.rst:193
@@ +192,3 @@
+more independent from each other, while the second proposal
+encourage better code sharing and refactoring across projects, for example
+reusing a datastructure initially in LLDB by moving it into libSupport. It
----------------
Rewrote, but I suspect we'll need some other rounds. Suggestion welcome.

================
Comment at: docs/Proposals/GitHubMove.rst:203
@@ +202,3 @@
+and clang-tools-extra is not useful. With the monorepo, we can move code around
+as we wish and preserve history.
+With the multirepo, moving clang-tools-extra into clang would be
----------------
Can you provide an example where the history of a single file *contents* can be preserved without pulling all the source repository entirely?
I'd like to try it and see how git log/git blame deals with that.


================
Comment at: docs/Proposals/GitHubMove.rst:209
@@ +208,3 @@
+Some concerns have been raised that having a single repository would be a burden
+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
----------------
You're welcome to suggest merits of the multi-repo proposal to balance.

================
Comment at: docs/Proposals/GitHubMove.rst:231
@@ +230,3 @@
+
+Under the multirepo, things are more involved.  We describe here the proposed
+solution.
----------------
Please provide a replacement for this sentence.

================
Comment at: docs/Proposals/GitHubMove.rst:453
@@ +452,3 @@
+
+Today this is easy for subversion users, and possible but not straighfoward for
+git-svn users. Few Git users try to e.g. update LLD or Clang in the same commit
----------------
Do you have an alternative to suggest?

================
Comment at: docs/Proposals/GitHubMove.rst:571
@@ +570,3 @@
+multirepo situation explained above. The granularity is finer since each
+individual commits in every sub-projects participate in the bisection. The
+bisection script does not need to include the `git submodule update` step.
----------------
If you have a way to *guarantee* it, I'm willing to hear about it. Right now, I don't believe it is possible without implementing it on the git hosting itself.


================
Comment at: docs/Proposals/GitHubMove.rst:621
@@ +620,3 @@
+
+Note however that many users of the monorepo would benefit from having all of
+the pieces needed for a full toolchain present in one repository. And for
----------------
Removed the paragraph

================
Comment at: docs/Proposals/GitHubMove.rst:628
@@ +627,3 @@
+they aren't forced to download or check out all of llvm, clang, etc. just to
+make a change to libcxx.)
+
----------------
We're talking about libcxx in the monorepo proposal?
Assuming yes, can you give an example of workflow that would be changed compared to today?

================
Comment at: docs/Proposals/GitHubMove.rst:636
@@ +635,3 @@
+
+Example of a working version:
+
----------------
(Already addressed above)

================
Comment at: docs/Proposals/GitHubMove.rst:582
@@ +581,3 @@
+multirepo situation explained above. The granularity is finer since each
+individual commits in every sub-projects participate in the bisection. The
+bisection script does not need to include the `git submodule update` step.
----------------
I did a minor rewording (we're on a different support level here between the two solutions, which need to be conveyed somehow). 


https://reviews.llvm.org/D24167