[PATCH] D24167: Moving to GitHub - Unified Proposal

[Mehdi Amini via llvm-commits]

> On Oct 12, 2016, at 3:42 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 
>> 
>> On 2016-Oct-12, at 15:24, Mehdi Amini <mehdi.amini at apple.com> wrote:
>> 
>>> 
>>> On Oct 12, 2016, at 3:11 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>>> 
>>> 
>>>> On 2016-Oct-12, at 14:54, Mehdi Amini <mehdi.amini at apple.com> wrote:
>>>> 
>>>>>> + * Refactoring across projects is not frienly: taking some functions from clang
>>>>> 
>>>>> s/frienly/friendly/
>>>>> 
>>>>>> +   to make it part of a utility in libSupport wouldn't carry the history of the
>>>>>> +   code in the llvm repo, preventing recursively applying `git blame` for
>>>>>> +   instance.
>>>>> 
>>>>> Please add: "However, this is no different than the current state.”
>>>> 
>>>> I can compromise with "However, this is not very different than the current state.”
>>>> 
>>>> Although today I can move code across subproject in a single commit and git blame works in the monorepo export.
>>>> 
>>> 
>>> I'm convinced you could set up a monorepo mirror even if the canonical source uses multirepo.
>> 
>> Sure, but aggregating the individual repo does not bring the possibility to have a single commit in the aggregation repo that moves code across the original sub-repo, while now you can (the canonical repository supports it). 
>> 
>> I’m skeptical that tooling can really help in practice with this (outside of limited trivial cases).
>> 
>>> The current state is: multiple subproject refactorings are not friendly (require heavy tooling).  Adopting multirepo doesn't change that much.  It will still be unfriendly, but require heavy tooling.
>>> 
>>> How about: "However, this is similar to the current state."?
> 
> Let me repeat:
> 
> How about: "However, this is similar to the current state.”?

Let’s look at the full paragraph, I’d write:

Refactoring across projects is not friendly: taking some functions from clang
to make it part of a utility in libSupport wouldn't carry the history of the
code in the llvm repo, preventing recursively applying `git blame` for
instance. However, this is not very different than how most people are
Interacting with the repository today, by splitting such change in multiple
commits.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161012/d063e643/attachment.html>