Proposal for the transition timetable for the move to GIT

[Joseph Myers]

On Fri, 27 Dec 2019, Alexandre Oliva wrote:

> That depends on the used tool.  A reproducible one, or at least one that
> aimed at stability across multiple conversions, could make this easier,
> but I guess reposurgeon is not such a tool.  Which suggests to me we
> have to be even more reassured of the correctness of its moving-target
> output before we adopt it, unlike other conversion tools that have long
> had a certain stability of output built into their design.

reposurgeon results are fully reproducible (by design, the same inputs to 
the same version of reposurgeon should produce the same output as a 
git-fast-import stream, and git should then produce the same objects given 
the same fast-import stream) - note that "same inputs" here includes the 
same bug data used for adding commit summary lines (and of course past 
commit messages, when people fix commit messages in SVN that consequently 
changes the hashes for all descendent commits in any git conversion).  It 
is, however, a tool that works with the *global* commit history.

Most of reposurgeon's own tests verify an output fast-import stream is as 
expected and thus would be liable to fail if the output were not 
reproducible as a function of the input.

Even with two completely separate conversions done with different tools, 
adding a new branch into a git repository should not be more complicated 
than a rebase operation, possibly with some fixups to merge commit 
parents.

-- 
Joseph S. Myers
jsm@polyomino.org.uk