[PATCH] D24167: Moving to GitHub - Unified Proposal

Mon Oct 3 14:02:33 PDT 2016

beanz added a comment.

After this round of feedback I'm removing myself from this discussion.

> mehdi_amini wrote in GitHubMove.rst:249
> 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.

From the beginning I said:

> It won't be perfect, but it should be good enough for sorting commits in close proximity...

If you want to debate that statement we can do so, but I would prefer not to in this thread.

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

You don't get to dictate how the proposal in opposition to your preferred approach is written. I think you've been pretty clear about being against the multi-repo proposal, so I don't see how your opinion factors in to the final document, which shouldn't be opinion based.

> mehdi_amini wrote in GitHubMove.rst:207
> >> "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.

You asked for feedback. If you want to disregard it that is your decision.

> mehdi_amini wrote in GitHubMove.rst:214
> 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.

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

git-filter-branch can preserve the history of a single file. It does not follow renames, however if you know a file was renamed, you can use git-filter-branch's --tree-filter or --index-filter flags to perform more complicated slicing of the repository to preserve that history. If you're unfamiliar with the types of things you can do with filter branch, this article gives a good overview (https://devsector.wordpress.com/2014/10/05/advanced-git-branch-filtering/).

> mehdi_amini wrote in GitHubMove.rst:601
> > 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.

Saying the workflows is "similar" is not a subjective wording.

Today someone who writes:
`svn co svn co http://llvm.org/svn/llvm-project/llvm/trunk`
Under the mono-repo could write something like:
`svn co http://github.com/llvm/llvm-project/master/llvm`
Under the multi-repo could write something like:
`svn co http://github.com/llvm/llvm/master/`

The *workflow* of `svn co` -> `svn add` -> `svn commit` is *similar* in all cases.

https://reviews.llvm.org/D24167