Date: Wed, 20 May 2020 17:09:29 -0400 From: Ed Maste <emaste@freebsd.org> To: freebsd-git@freebsd.org Subject: "git replace" experimentation Message-ID: <CAPyFy2B2t-y%2Bq8kviVfvTgCYZLhA%2Bu_STX7=gFvPDeGe1GEqSQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2B2t-y%2Bq8kviVfvTgCYZLhA%2Bu_STX7=gFvPDeGe1GEqSQ>