[PATCH] D24167: Moving to GitHub - Unified Proposal

[Justin Lebar via llvm-commits]

jlebar added inline comments.


> kparzysz wrote in GitHubMove.rst:355
> Even with sparse checkout?  Am I going to see new files in projects that were not originally included in the sparse checkout?

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.

> kparzysz wrote in GitHubMove.rst:366
> A conflicting change would have to affect the same file.  This is regardless of whether it's monorepo or multirepo.  Am I missing something here?
> 
> Rebasing is always a good practice, but it's not strictly required.  If there are no conflicts, the system will just add the change on top of the current ToT, even if they have not been fetched to the local repo.

> Rebasing is always a good practice, but it's not strictly required. If there are no conflicts, the system 
>  will just add the change on top of the current ToT, even if they have not been fetched to the local 
>  repo.

That is what git-svn will do, yes.  But that's not pure git's behavior.

https://reviews.llvm.org/D24167