Reconsider switching from svn to git?

[Warner Losh]

On Tue, Feb 21, 2017 at 1:22 PM, Ed Maste <emaste at freebsd.org> wrote:
> On a different (non-public) list we've been discussing git in FreeBSD,
> and I wanted to discuss one of Warner's points further. Before asking
> I asked for approval to quote the message here.
>
> On 21 February 2017 at 11:36, Warner Losh <imp at bsdimp.com> wrote:
>>
>> However, there's one big drawback we don't have with svn: it destroys
>> history. Rebasing branches destroys history, as does deleting
>> branches. In svn, you can always get that information back, but not so
>> with git. It's very easy to do these operations and quite difficult to
>> undo them.
>
> I'd like to understand this better. In my opinion, in general
> commit(s) should stand alone -- any metadata associated with the
> commit (PR numbers, review links, etc.) should be in the commit
> message itself. The fact that they were originally done on a branch
> should only be an "implementation detail." So I agree rebasing and
> committing loses that history, but think in general it should not
> matter.

For small commits, I agree. For longer lived project branches,
however, there can be issues. Specifically, in svn, when you delete a
branch, it just marks it as empty, but you can get back to it at any
point in the branch. In git, however, deleting a branch deletes the
meta-data needed to get back to the branch (as does rebasing). We'd
need some way to administratively prohibit this, perhaps, for the
source of truth repo. I have no clue if this is possible with git,
just putting it out there.

There's also a number of advantages / disadvantages to merging vs
rebasing + fast-foward to pushing changes upstream. I'm curious what
people are thinking here.

>> If, and this is a big if, we go to using git, I'd like to *STRONGLY*
>> request that we not change the hashes we have on github today. There's
>> lots of people with branches from that and changing the hashes would
>> make them all useless. Well, not completely useless, but quite
>> difficult to recover from unless the branches were simple without
>> merges.
>
> This is a very tricky issue. I agree that there's a(n incredibly)
> large cost with changing existing hashes, and previously argued that
> it was an absolute nonstarter. Also, I think this is independent of
> switching to git as the source of truth: we have the same open issue
> with the current svn2git mirror.

I know. I know the pain it will cause for Netflix should that issue be resolved.

> That said, I also strongly believe that, as long as SVN is the "source
> of truth" repo, the git conversion must be reproducible by third
> parties. I believe developers and others who consume FreeBSD via git
> must be able to validate that the data and metadata are consistent
> between svn and git. Unfortunately today even the subversion mirrors
> (svn.freebsd.org) have inconsistent metadata relative to
> repo.freebsd.org, so it's not currently possible for end users to
> validate the svn2git conversion.

As one of the users that would be affected by hash changes, I'm
finding that argument less persuasive given the pain I know it will
cause.

> I've briefly discussed with uqs@ what it would entail to migrate to a
> "fixed" view of the history, and believe it's possible to facilitate a
> relatively painless migration. It could look roughly like:
>
> 1. Broadly announce the plan
> 2. Make a new alias for current master (e.g. master-legacy)
> 3. Start a new, reproducible conversion and push to a new master (master-ng)
> 4. As new commits are made to SVN update both master-ng and master-legacy
> 5. Provide guidance on migrating both rebase- and merge-based
> workflows to master-ng
> 6. Give notice of upcoming switch in what master points to
> 7. Switch master from master-legacy to master-ng
> 8. Stop updating master-legacy if/when it becomes infeasible to
> continue doing so, or when it's no longer used

If there were tools to help migrate, that would be useful. But I'm
unsure what those might be since many of git's most powerful features
don't work when you don't have a proper shared ancestor that's recent.

Though a plan like that might be able to mitigate some of our concerns
given the rather quirky way we import sources at Netflix (we do them
as a subtree and do odd things to create merge points). It would take
some experimentation to be able to know if this is a viable path
forward. Our master tree is a twisty maze of commits, merges, etc that
bedevil automation.

As for switching source of truth, what's the thinking on $FreeBSD$ and
the currently nice property of it that it includes the branch /
release in the path.

Anyway, don't take concerns I have for opposition to a switch, just
nerves that need to be quelled a bit first :)

Warner