[PATCH] D24167: Moving to GitHub - Unified Proposal

[Mehdi AMINI via llvm-commits]

mehdi_amini marked 2 inline comments as done.
mehdi_amini added inline comments.


> beanz wrote in GitHubMove.rst:249
> The automation will run. It will collect a list of commits that have been pushed to each repository since the last time the script ran. It will then sort them by committer timestamp order, and commit one at a time to the umbrella repo as submodule updates.
> 
> We can setup the automation to run based on GitHub WebHooks, and periodically in case a WebHook gets dropped.
> 
> There is no race condition that I see.
> 
> If we need to support revlocked changes, (and I'm not convinced this is the case since they are by far a minority of commits) we can support them via annotations on the commit messages. We can teach the automation to look for markers in the commit message denoting that it is revlocked to other changes, and we can have it group revlocked changes together.
> 
> There is no need for server-side hooks, and this solution would work as well as any mirroring system. I don't believe there is any need for this solution to be bulletproof, but I see no reason why it cannot be as robust as the single-project mirrors that the mono-repo proposal includes.

> The automation will run. It will collect a list of commits that have been pushed to each repository since the last time the script ran.

Atomically?

> There is no race condition that I see.

Did you read my sequence 1-7 that describes an example of race?

> but I see no reason why it cannot be as robust as the single-project mirrors that the mono-repo proposal includes.

Define "robust". The single-project mirrors have a very well *deterministic* algorithm to construct, and reconstruct them at will, you don't have one for the multi-repo. That's not "robust" to me.

> beanz wrote in GitHubMove.rst:207
> That is 'making easier' not 'encouraging'. Personally I fall to 'grep' way before I fall to 'git grep' for things like this, and I don't think the monorepo has any enforcement of this.

> That is 'making easier' not 'encouraging'.

"All the source is there //by default//"  *+* "making it easier" => why I wrote "encouraging".

> Personally I fall to 'grep' way before I fall to 'git grep' for things like this, and I don't think the monorepo has any enforcement of this.

Not sure why "enforcement" comes into play here?

> beanz wrote in GitHubMove.rst:214
> In your example of moving clang-tools-extra there would be *no* need for loss of history at all. There is no need for filter-branch. You can literally reformat clang-tools-extra to be under tools/extra/ and merge the whole tree into the clang master branch.
> 
> The only point where you would lose any history at all is if you were trimming one part of a repository into another repository, and even in that situation you can minimize the losses pretty well using filter-branch and index scripts. It is complicated but possible.

So do you have anything *concrete* that could be added here, be practical (something we'd be willing to encourage in the future),  be understandable by any dev, *and* not take > 20 lines to describe?

> beanz wrote in GitHubMove.rst:350
> Can you add per-project sizes?

That'd make a long list, how should it be presented?

> beanz wrote in GitHubMove.rst:445
> I think it is worth noting under the multi-repo proposal something along the lines of:
> 
> > Because we will be maintaining a linear history you can perform a timestamp based checkout of each project repository with the following command:
> > 
> >   git checkout 'master@{...}'
> > 
> > 
> > Additionally you can use the umbrella repository...
> 
> If you want to also add the timestamp checkout to the mono-repo proposal, that makes sense too. I just think it is worth noting under the multi-repo proposal that timestamp based checkouts are expected to work due to the linear history requirement, which means you don't need the submodule repo.

Are you sure that this command does what you think it does?
If I read correctly the doc, it is looking at your *reflog*, not the history.

The right one should be something like `git checkout ```git rev-list -n 1 --before="2009-07-27 13:37" master``

> I just think it is worth noting under the multi-repo proposal that timestamp based checkouts are expected to work due to the linear history requirement, which means you don't need the submodule repo.

OK that wasn't clear to me the first time.

> beanz wrote in GitHubMove.rst:601
> Maybe rather than "the same way" "with similar workflows to today"?

I'm still missing what would be similar for someone integrating multiple projects from SVN today (assuming such downstream integrator exists) with the multi-repo?

https://reviews.llvm.org/D24167