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. > 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. 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. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>