llvm dev - Jun 2016 - [cfe-dev] [lldb-dev] GitHub anyone?

On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev
<lldb-dev at lists.llvm.org> wrote:
> Apparently I wasn't very clear: llvm and clang (and the others
projects) would be simple decoupled, individual git repositories. You would be
able to check them out however you want and commit to them individually.
> There would be an extra "integration repository" on top that
would only provide the service that tells "r12345 is llvm:36c941c
clang:eaf492b compiler-rt:6d77ea5". This repository should be managed
transparently by some server-side integration.
This actually sounds like a really good idea even if a full move to
git gets blocked for some reason. It seems like it could be a fairly
common requirement: I don't suppose you know of an existing script
that could do it? If not, I may take a stab.

Tim.

> On Jun 2, 2016, at 11:03 AM, dag at cray.com wrote:
> 
> Tim Northover via cfe-dev <cfe-dev at lists.llvm.org> writes:
> 
>> On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev
>> <lldb-dev at lists.llvm.org> wrote:
>>> Apparently I wasn't very clear: llvm and clang (and the others
>>> projects) would be simple decoupled, individual git
>>> repositories. You would be able to check them out however you want
>>> and commit to them individually.
>>> There would be an extra "integration repository" on top
that would
>>> only provide the service that tells "r12345 is llvm:36c941c
>>> clang:eaf492b compiler-rt:6d77ea5". This repository should be
>>> managed transparently by some server-side integration.
>> 
>> This actually sounds like a really good idea even if a full move to
>> git gets blocked for some reason. It seems like it could be a fairly
>> common requirement: I don't suppose you know of an existing script
>> that could do it? If not, I may take a stab.
> 
> How do you get monotonically increasing number with a history graph?
I think what we're trying to get is a "pushed" revision number,
i.e. tracking the state of the upstream repositories at a given time.

> There are multiple ways to linearize the history.
> 
> You can simply disallow merges I guess but that seems not much better
> than just sticking with SVN.  GitHub's pull request model kind of
breaks
> down if you can't do merges.
Github has an automatic "squashed" mode for pull requests now, I
haven't tested in practice but it may help.

-- 
Mehdi