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

[Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>]

> On Dec 30, 2019, at 3:18 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> 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).

Thanks for catching this.  This is fallout from incremental rebuilds (rather than fresh builds) of gcc-reparent repository.  Incremental builds take about 1h and full rebuilds take about 30h.  I'll switch to doing full rebuilds.

--
Maxim Kuvyrkov
https://www.linaro.org