[llvm-dev] [RFC] One or many git repositories?

[Daniel Sanders via llvm-dev]

> -----Original Message-----
> From: Renato Golin [mailto:renato.golin at linaro.org]
> Sent: 22 July 2016 11:40
> To: Daniel Sanders
> Cc: Pete Cooper; LLVM Developers
> Subject: Re: [llvm-dev] [RFC] One or many git repositories?
> 
> On 22 July 2016 at 11:16, Daniel Sanders <Daniel.Sanders at imgtec.com>
> wrote:
> > There's another reason I've been staying quiet too which is that past
> > experience with VCS migrations has taught me that people tend to over-
> value
> > some things and that discussion tends not to convince people in advance of
> > direct experience. I think some of these topics will end up being moot once
> > we've moved to git and gotten used to it. For example, I've seen talk of
> > wanting to preserve linear history which is understandable since it's quite
> > nice to have. However, I suspect we'll drop that after a month or so as
> > people find 'git push' doesn't work very well on a high traffic repo and
> > start looking for alternatives. At that point I think we'll end up switching
> > to pull requests and accepting non-linear history. Similarly, I think the
> > desire for incremental revision numbers will gradually fade as people get
> > used to git.
> 
> This is valid on a monolithic model, and that is one of the reasons I prefer it.
>
> Today, I personally prefer the Git model (merges, pull requests, fuzzy
> history), but I haven't always done so. The more I learnt how to use
> Git, the more I realised how valuable the "confusing model" is for
> distributed development.

Same here, accepting the git model was a gradual thing for me. One particular
milestone was realizing that I didn't really need any logic in the commit id's
because I was only copy/pasting them or using things like 'my-branch^^'.

> Trying to force Git into an SVN model for the long term feels like
> creating a niche that will be hard to work with (no hard evidence,
> pinch of salt and all that).
> 
> I don't maintain a downstream fork, so I can't speak for that niche.
> But forks in GitHub (all, not just LLVM's) seem to be fine merging
> their patches over the original repository.
> 
> What this feels to me is that we were too complacent with the old
> model and were slowly creeping Git support in an SVN world, and now we
> realised how unusual is our "requirements".
> 
> Maybe you're right. Maybe moving to yet another model that satisfies
> those requirements would be a step back, because we'd be setting in
> stone a rule that was accommodated, not designed.

I don't see it as a step backwards but rather as a way of making people
comfortable with the switch. I think opinions may gradually shift towards
a more conventional git model after the switch but that doesn't necessarily
detract from the value of a more svn-ish model if having one helps people
switch.

> Maybe we should propose a third model: Use Git like Git. Pull requests and
> all.
> 
> As a quick recap of the things could go wrong, here's a
> back-of-the-envelope idea of what could go wrong...
> 
> Changes that are the same as in linear monolithic core with external projects:
> 
> * the repositories themselves will have to adapt
> * the build system (CMake and all)
> * how the non-core repositories interact (relates to build system, bisect)
> * all public forks (GitHub and others)
> * all downstream forks (Many current LLVM active development affected)
> 
> New problems will be created:
> 
> * public and downstream forks that *rely* on linear history

Do you have an example in mind? I'd expect them to rely on each 'master' being
an improvement on 'master^'. I wouldn't expect them to be interested in how
'master^' became 'master'.

> * validation (buildbots will have to be re-written, or we'd have to
> move to Jenkins, pull-request testing, etc)

Assuming the goal is to preserve what we have rather than improve it, buildbot
will be fine without any changes (beyond switching the source steps from svn to
git of course) whichever model we pick. It would just check out the latest 'master'
on each build like it currently does for trunk. 

> * bisection (all our current tools will have to understand Git)
> * library dependencies will be hard to bisect, because they won't be
> in the same repository with the same history. This happens today in
> GNU-land with binutils, glibc, etc.
> 
> All in all, not *that* different from the linear monolithic proposal,
> and in my opinion, a future facing design, not a past driven
> conformance.
> 
> cheers,
> --renato