[PATCH] D24167: Moving to GitHub - Unified Proposal

[Mehdi AMINI via llvm-commits]

mehdi_amini added inline comments.


> beanz wrote in GitHubMove.rst:249
> I've updated my automation (https://github.com/llvm-beanz/llvm-submodules) to make one umbrella commit per commit to sub-project repository. This has a single commit granularity. That was the original point I was arguing. It works. It is done.
> 
> Is it perfect? No. There are a number of situations where the order of the commits to the submodule can be impacted by the order and proximity of commits to the project repositories. That is irrelevant to the point I was making. I'm more than happy to debate with you about whether or not that matters, but that is a separate issue from what I was pointing out.
> 
> Do we need to belabor this further, or will you update the document based on my feedback?

You're moving goal posts. Your previous message said that there is no race, while now you're eluding it with "There are a number of situations where...".

Also you're changing the definition of the multi-repo as I was foreseeing it. I think it is worse, and if we were to adopt the multi-repo proposal, I would be totally against this.

Now, *just to please you*, because again I don't think it does any good to this proposal, I'll re-formulate making clear that:

1. update in the multi-repo are single commits based.
2. commits can be in different orders.
3. it does not handle cross-project commits.

> beanz wrote in GitHubMove.rst:207
> > "All the source is there by default"
> 
> This is what makes it easier. Your math is double counting it. I disagree with your wording here. I've told you I disagree. You can continue to disregard my feedback or you can fix it. The choice is yours.

>> "All the source is there by default"
> 
> This is what makes it easier.

Sorry, but I mentioned earlier `git grep` and you answered `That is 'making easier'`. 
All the source presents by default is more than making it easier.

> I disagree with your wording here. I've told you I disagree.

I strongly disagree with your disagreement here.

> beanz wrote in GitHubMove.rst:214
> You gave an example that is factually incorrect. I'm asking you to fix it. That is concrete. In my earlier comment I told you why your example was incorrect. You can remove the example, or come up with an alternative. That is your choice. What you cannot do, is use this factually inaccurate example.

The current spelling (Friday, 3:51pm) is: "With the multirepo, moving clang-tools-extra into clang would be more complicated than a simple `git mv` command, and the history of the refactored code won't be available from the new place."
I can change the example to: "Refactoring some functions from clang to make it a utility in one of the llvm/lib/Support file to share it across sub-projects wouldn't carry the history of the code in the llvm repo."

That said, I asked you on 9/9 (over 3 weeks ago) "Can you provide an example where the history of a single file *contents* can be preserved without pulling all the source repository entirely? I'd like to try it and see how git log/git blame deals with that."  
You haven't been able to provide me with this. So you can claim whatever you want about "factual innacuracy", you still failed to provide counter facts to support your claim.

> beanz wrote in GitHubMove.rst:601
> I strongly suspect that very few users are using a single SVN checkout that contains more than one sub-project. If you discount that workflow, the workflow for interfacing using the GitHub SVN bridge is very similar whether you are using one repo or many.
> 
> Additionally, with the mono repo the combined SVN workflow is actually a lot better than with SVN today. It is way less fragile since you aren't doing sub-directory checkouts. This means you don't run the risk of inadvertently running `svn up` and pulling down way more than you wanted.

> If you discount that workflow, the workflow for interfacing using the GitHub SVN bridge is very similar whether you are using one repo or many.

"Very similar" is subjective, to me it can't be similar as long as there is no longer a single revision number.

> Additionally, with the mono repo the combined SVN workflow is actually a lot better than with SVN today. It is way less fragile since you aren't doing sub-directory checkouts. This means you don't run the risk of inadvertently running svn up and pulling down way more than you wanted.

I don't understand what you mean here.

https://reviews.llvm.org/D24167