[PATCH] D24167: Moving to GitHub - Unified Proposal

[Justin Lebar via llvm-commits]

jlebar added inline comments.


> kparzysz wrote in GitHubMove.rst:355
> > 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...

> My concern is that the "rebuild and retest" approach may take long enough to require another rebase...

This isn't a function of the monorepo.  You choose when to rebuild/retest, and that's orthogonal to the repository structure.  If "rebuild/retest only when there were changes to files I changed" is what you want to do, you can still do that.  You can ask that question of git before pushing.  Or you could ask "have any of the projects I care about changed?"  Or you could ask a different question.  And you could ask those questions of the monorepo, or the multirepo (although it might be a bit more work in the multirepo -- I say "might" so beanz doesn't jump on me).

In this sense it's safer than SVN, which assumes that you only care about retesting if there were modifications to files you also changed.

https://reviews.llvm.org/D24167