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

[Renato Golin via llvm-dev]

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.

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.

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