This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposal for the transition timetable for the move to GIT
On Sun, 29 Dec 2019, Maxim Kuvyrkov wrote:
> With the "Missed merges" problem (see below) I don't see how reposurgeon
> conversion can be considered "ready".
It aims to be conservatively safe regarding merges, erring on the side of
not adding incorrect merges if in doubt. Because of the difficulty in
matching SVN and git merge semantics, it's inherently hard to define
unambiguously exactly which merges are correct and which are cherry-picks
or erroneous. I think extra merges are something nice-to-have rather than
critical.
The case you mention is one where there was a merge to a branch not from
its immediate parent but from an indirect parent. I don't think it would
be hard to support detecting such merges in reposurgeon.
> Reposurgeon-6a conversion has authors "12:46:56 1998 Jim Wilson" and "2005-03-18 Kazu Hirata". It is rather obvious that person's name is unlikely to start with a digit.
These are already fixed in bugdb.py since that conversion, as part of the
general review of authors to fix typos and make them more uniform.
> Reposurgeon-6a conversion misses many authors, below is a list of people
> with names starting with "A".
>
> Akos Kiss
This is an example where the originally added ChangeLog entry was
malformed (had the date in the form "2004-0630"), so a conservatively safe
approach was taken of using the committer rather than trying to guess what
a malformed ChangeLog entry means and risk extracting nonsense.
I expect other cases are being similarly careful in cases where there was
a malformed ChangeLog entry or a commit edited ChangeLog entries by other
authors so leaving its single-author nature ambiguous. Parsing
ChangeLogs, especially where malformed entries are involved, is inherently
a heuristic matter.
--
Joseph S. Myers
jsm@polyomino.org.uk