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

[Robinson, Paul via llvm-dev]

> >> * 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'.
> 
> Paul Robinson was outlining some of the issues he had with git
> history. I don't know their setup, so I'll let him describe the issues
> (or he may have done so already in some thread, but I haven't read it
> all).

Since you asked...

The key point is that a (basically) linear upstream history makes it
feasible to do bisection on a downstream branch that mixes in a pile
of local changes, because the (basically) linear upstream history can
be merged into the downstream branch commit-by-commit which retains
the crucial linearity property.

We have learned through experience that a bulk merge from upstream is
a Bad Idea(tm).  Suppose we have a test that fails; it does not repro
with an upstream compiler; we try to bisect it; we discover that it
started after a bulk merge of 1000 commits from upstream.  But we can't
bisect down the second-parent line of history, because that turns back
into a straight upstream compiler and the problem fails to repro.

If instead we had rolled the 1000 commits into our repo individually,
we'd have a linear history mixing upstream with our stuff and we would
be able to bisect naturally.  But that relies on the *upstream* history
being basically linear, because we can't pick apart an upstream commit
that is itself a big merge of lots of commits. At least I don't know how.

Now, I do say "basically" linear because the important thing is to have
small increments of change each time.  It doesn't mean we have to have
everything be ff-only, and we can surely tolerate the merge commits that
wrap individual commits in a pull-request kind of workflow.  But merges
that bring in long chains of commits are not what we want.
--paulr