"git replace" experimentation

Ed Maste emaste at freebsd.org
Wed May 20 21:09:44 UTC 2020


One of the issues the working group discussed is a desire to possibly
rewrite old history after migrating. There are a number of oddities
from the CVS to Subversion conversion that persist in a Subversion to
git conversion, and we might like to clean these up "eventually." That
said, we do not want any such work to hold up the migration.

I investigated "git replace", documented as:

NAME
       git-replace - Create, list, delete refs to replace objects

SYNOPSIS
       git replace [-f] <object> <replacement>
       ...

This replaces adds a record that <object> should instead be
<replacement>. For example, imagine we have a FreeBSD git repo
converted from Subversion converted from CVS (commits ordered top to
bottom):

(G)
 |
(H)
 |
(I)
 |
(J)

assuming I and J are "good" commits that we want to keep, and G and H
are oddities resulting from the CVS conversion that we'd really prefer
to merge into one commit.

Then, also assume we have another repo converted from CSRG SCCS history:

(A)
 |
(B)
 |
(C)

we could rewrite commits G and H above into a new G' from C, and do

git replace H G'

which gives us history without the oddities:

(A)
 |
(B)
 |
(C)
 |
(G') (replaced)
 |
(I)
 |
(J)

Internally git handles this with entries in .git/refs/replace - for instance:
$ cat .git/refs/replace/f2c6d997d54756ff19a35dd10a6bac76724c811d
53c878b7ea114199534f3f6138d6c23987cc1b43

As far as I know git does not automatically fetch or push the replace
refs, which is fine if we're using this just to provide an
alternative, cleaned-up view of ancient history.

What does this mean for the git migration? We should proceed with the
effort as is and not be held up trying to "correct" odd commits prior
to src r179447, the first real SVN commit. With git replace we can
later retrofit a correct view of the history, and "git log", "git
blame" etc. will do the right thing.


More information about the freebsd-git mailing list