[PATCH] D24167: Moving to GitHub - Unified Proposal
Duncan P. N. Exon Smith via llvm-commits
llvm-commits at lists.llvm.org
Wed Oct 12 15:58:17 PDT 2016
> On 2016-Oct-12, at 15:56, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
>>
>> 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
s/change/changes/
LGTM.
> commits.
More information about the llvm-commits
mailing list