Re: Proposal for the transition timetable for the move to GIT

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 17 Sep 2019, Richard Earnshaw (lists) wrote:

> Doing this over the new year holiday period has both advantages and
> disadvantages.  On the one hand the traffic is light, so the impact to most
> developers will be quite low; on the other, it is a holiday period, so getting
> the right key folk to help might be difficult.  I won't object strongly if
> others feel that slipping a few days (but not weeks) would make things
> significantly easier.

I think slipping it one week is better so more people are around to check 
things at the transition time.

I'd also like to add: for any approach using a fresh, clean conversion, we 
should ensure the existing commit ids and git-only branches remain 
available somewhere.  There are two possible approaches:

1. Keep the existing git-svn repository available, read-only, in some 
(renamed) public location.

2. Put the objects and (renamed) refs into the new repository alongside 
the cleanly converted history.  Because most blob and tree objects should 
be identical between the conversions (with it mainly being commit and tag 
objects that aren't shared between the versions of the history), that 
shouldn't enlarge the repository that much.  I've previously suggsted a 
git command (untested) along the following lines (plus repacking the 
repository afterwards) to do this:

git fetch git://gcc.gnu.org/git/gcc.git \
    'refs/heads/*:refs/heads/git-old/*' \
    'refs/remotes/*:refs/heads/git-svn-old/*' \
    'regs/tags/*:refs/tags/git-old/*'

(It is of course possible to do (1) and then decide at a later point to do 
(2) as well.)

-- 
Joseph S. Myers
joseph@codesourcery.com