[PATCH] D24167: Moving to GitHub - Unified Proposal

Mehdi AMINI via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 3 13:52:12 PDT 2016


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

> Even with sparse checkout? Am I going to see new files in projects that were not originally included in the sparse checkout?

If you mean are you seeing them when typing `ls` in your terminal, then no you don't. I can add "unless you're using a sparse checkout" to make it more clear.

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

> 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?

The point was that when you run `git pull --rebase`, you have new changes, and even without an explicit "diff conflict" your changes that you're about to push may use an API that have changed upstream. Note today this is not addressed: SVN will blindly accept the push and break the build.

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

As Justing mentions, this is not true with `git push` AFAIK. You **have to** `pull` (merge or rebase) before being able to push.

https://reviews.llvm.org/D24167





More information about the llvm-commits mailing list