[PATCH] D24167: Moving to GitHub - Unified Proposal

[Krzysztof Parzyszek via llvm-commits]

kparzysz added inline comments.


> jlebar wrote in GitHubMove.rst:355
> What do you mean by "see"?
> 
> In order to push a commit without `-f`, the commit's parent commit must be the current remote head.  The commits in git are unaffected by sparse checkout.  So, if you have a commit you want to push, you will need to rebase it atop current remote HEAD -- you'll have to do this rebase even if you're using sparse checkouts and all of the changes between your current base revision and current remote HEAD are to subprojects that you don't have checked out.
> 
> If you don't like this, you can continue to use the single-subproject mirrors exactly as you currently do (with git-svn and everything), by changing the configs as explained elsewhere in this document.  But I've been using a monorepo (http://github.com/llvm-project/llvm-project) for months now.  I've pushed maybe 30 commits using my custom script (https://github.com/jlebar/llvm-repo-tools) and this necessity to rebase hasn't once been an annoyance for me.

> What do you mean by "see"?

I'm referring to this (and the rest of this paragraph):
"However when you fetch you'll likely pull in changes to sub-projects you don't care about."

The intent wasn't clear---I wasn't aware of the requirement about parent commit (I use SVN for upstreaming changes).  But that brings another question: what is the anticipated frequency of commits to the monorepo?  My concern is that the "rebuild and retest" approach may take long enough to require another rebase...

https://reviews.llvm.org/D24167