Reconsider switching from svn to git?

[Ed Maste]

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.

> 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.

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.

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