[PATCH] D24167: Moving to GitHub - Unified Proposal

[Mehdi AMINI via llvm-commits]

mehdi_amini 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...

When you commit to SVN, you add a "patch" on top of the existing codebase. Unless there is a conflict your patch will be committed.
It does not mean it will build, since someone else may just have changed an API you're using in your patch.

The new monorepo won't be different from SVN on this aspect: you have the same frequency of commits, and you can run `git pull && git push` which is roughly equivalent to `git svn dcommit` today.
The thing is that between the `git pull` and the `git push`, you can also inspect what changed since your last build/check, and decide if you need to rebuild or not.

https://reviews.llvm.org/D24167