Proposal for the transition timetable for the move to GIT

[Joseph Myers]

On Sun, 29 Dec 2019, Richard Earnshaw (lists) wrote:

> gcc-reparent is better, but many (most?) of the release tags are shown
> as merge commits with a fake parent back to the gcc-3 branch point,
> which is certainly not what happened when the tagging was done at that
> time.

And looking at the history of gcc-reparent as part of preparing to compare 
authors to identify commits needing manual attention to author 
identification, I see other oddities.

Do "git log egcs_1_1_2_prerelease_2" in gcc-reparent, for example.  The 
history ends up containing two different versions of SVN r5 and of many 
other commits.  One of them looks normal:

commit c01d37f1690de9ea83b341780fad458f506b80c7
Author: Charles Hannum <mycroft@gcc.gnu.org>
Date:   Mon Nov 27 21:22:14 1989 +0000

    entered into RCS
    
    
    git-svn-id: https://gcc.gnu.org/svn/gcc/trunk@5 138bc75d-0d04-0410-961f-82ee72b054a4

The other looks strange:

commit 09c5a0fa5ed76e566668cc67f3d72bf397277fdd
Author: Charles Hannum <mycroft@gcc.gnu.org>
Date:   Mon Nov 27 21:22:14 1989 +0000

    entered into RCS
    
    
    git-svn-id: https://gcc.gnu.org/svn/gcc/trunk@5 138bc75d-0d04-0410-961f-82ee72b054a4
    Updated tag 'egcs_1_1_2_prerelease_2@279090' (was bc80be265a0)
    Updated tag 'egcs_1_1_2_prerelease_2@279154' (was f7cee65b219)
    Updated tag 'egcs_1_1_2_prerelease_2@279213' (was 74dcba9b414)
    Updated tag 'egcs_1_1_2_prerelease_2@279270' (was 7e63c9b344d)
    Updated tag 'egcs_1_1_2_prerelease_2@279336' (was 47894371e3c)
    Updated tag 'egcs_1_1_2_prerelease_2@279392' (was 3c3f6932316)
    Updated tag 'egcs_1_1_2_prerelease_2@279402' (was 29d9998f523b)

(and in fact it seems there are *four* commits corresponding to SVN r5 and 
reachable from refs in the gcc-reparent repository).  So we don't just 
have stray merge commits, they actually end up leading back to strange 
alternative versions of history (which I think is clearly worse than 
conservatively not having a merge commit in some case where a commit might 
or might not be unambiguously a merge - if a merge was missed on an active 
branch, the branch maintainer can easily correct that afterwards with "git 
merge -s ours" to avoid problems with future merges).

My expectation is that there are only multiple git commits corresponding 
to an SVN commit when the SVN commit touched more than one SVN branch or 
tag and so has to be split to represent it in git (there are about 1500 
such SVN commits, most of them automatic datestamp updates in the CVS era 
that cvs2svn turned into mixed-branch commits).

-- 
Joseph S. Myers
joseph@codesourcery.com