On Sun, 29 Dec 2019, Eric S. Raymond wrote: > Joseph Myers <j...@polyomino.org.uk>: > > 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. > > We're working on it.
And the other example branch mentioned (redhat/gcc-9-branch) is a different case: if the merge from gcc-9-branch to redhat/gcc-9-branch had been done in the idiomatic way with modern SVN (i.e. naming the branch to merge from and letting SVN deal with identifying the revisions involved), I think reposurgeon would have handled it just fine. But the commit messages indicate the merge was done in an old-fashioned way (naming individual ranges of revisions to merge manually), which resulted in merge properties very slightly different from what SVN creates automatically. Now I understand what the difference is I expect we'll be able to fix that case as well. > As Joseph says, one of reposurgeon's design principles is "First, do no harm." > > And yes, changelogs are full of malformations and junk like this. I > saw and dealt with a lifetime's worth while converting the Emacs > history from bzr to git. > > If you try to interpret any random garbage in, you will assuredly > get garbage out when you least expect it. Often the cost of this > sort of mistake is not fully realized until it is far too late > for correction. This is *why* reposurgeon is conservative. > > The correct thing for reposurgeon to do is flag unparseable entry > headers for human intervention, and as of today it does that. Furthermore, we can compare authors in the different conversions to identify cases where, based on a manual review, Maxim's heuristics produce better results for a particular commit, and add those to the list of fixups in bugdb.py - and that way benefit both from reposurgeon making choices that are as conservatively safe as possible, which seems a desirable property for problem cases that haven't been manually reviewed, and from different heuristics helping suggest improvements in particular cases. -- Joseph S. Myers jos...@codesourcery.com
