> On Dec 30, 2019, at 3:18 AM, Joseph Myers <jos...@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 <mycr...@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 <mycr...@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
