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).
--
Joseph S. Myers
jos...@codesourcery.com
