Reconsider switching from svn to git?

Grzegorz Junka list1 at gjunka.com
Sat Feb 25 00:36:53 UTC 2017


I am not the recipients of these questions but would like to add some 
comments.

On 21/02/2017 20:22, Ed Maste 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.
>

Rebasing doesn't destroy history, just rewrites them. It creates as many 
commits as the original branch, but they are applied on top of the 
changed branch, so may differ from the original commits depending on 
what changes were in the original branch. However, this shouldn't matter 
since rebasing should NOT be used with branches that are public (were 
pushed to the remote server). That's precisely because rebase rewrites 
commits - if someone rebased 5 last commits in a branch which someone 
else already pulled, when merging these 5 commits back together there 
will be conflicts because the rebased commits don't match the original ones.

So, any public branches should be merged rather than rebased, and merge 
preserves all history, including the previous and next commits in the 
chain of changes. In order to reduce amount of commits it's also a good 
practice to squash the commits before merging. For example, someone 
works on a feature in a separate branch, then instead of merging that 
branch to the integration branch directly they create a squashed commit 
that contains all changes from that separate branch.

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

Grzegorz


More information about the freebsd-git mailing list