Reconsider switching from svn to git?

Ed Maste emaste at
Wed Feb 22 00:46:30 UTC 2017

On 21 February 2017 at 18:47, Warner Losh <imp at> wrote:
> 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.

Ok, we could easily disallow any destructive activity on a
source-of-truth git repo, including force (non-fast-forward) pushes
and branch deletion.

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

For relatively short-lived work-in-progress branches that are destined
for upstream FreeBSD I prefer the rebase model, where changes are
regularly rebased on HEAD. It might be more work in aggregate, and
might occasionally require repeating some portions of work. But I like
having a set of changes as a logical sequence ready to apply to head.

I hope others who maintain long-lived divergent branches not destined
for upstream FreeBSD can weigh in on their experiences.

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

Note that I'm explicitly advocating for us to keep the old hashes as
long as is practical, avoiding any imposed pain on a "flag day."

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

I'm not sure what tooling exists today to support this, but if it
doesn't exist today it's conceptually easy to write. We'd have a 1:1
correspondence between hashes in the "legacy" and "ng" sets, and so it
will be possible to perform an automatic migration without any human

This assumes the data is identical in the "legacy" and "ng" git
history, but if it's not we have larger problems.

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

Good question! IMO it's premature to worry about the issues inherent
in switching the source of truth (as it's currently not on the table).

Personally, I'd prefer that we lose $FreeBSD$ altogether. For the way
I interact with FreeBSD it causes grief more than solves any problem I

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

Not at all, this is one of the reasons I wanted to migrate this
discussion to the freebsd-git list. It's something that can't be
undertaken lightly. Any change needs to be planned, tested, and
deployed with ample advance notice and opportunity for discussion

More information about the freebsd-git mailing list