> On Dec 27, 2019, at 4:32 AM, Joseph Myers <j...@polyomino.org.uk> wrote: > > On Thu, 26 Dec 2019, Joseph Myers wrote: > >>> It appears that .gitignore has been added in r1 by reposurgeon and then >>> deleted at r130805. In SVN repository .gitignore was added in r195087. >>> I speculate that addition of .gitignore at r1 is expected, but it's >>> deletion at r130805 is highly suspicious. >> >> I suspect this is one of the known issues related to reposurgeon-generated >> .gitignore files. Since such files are not really part of the GCC >> history, and the .gitignore files checked into SVN are properly preserved >> as far as I can see, I don't think it's a particularly important issue for >> the GCC conversion (since auto-generated .gitignore files are only >> nice-to-have, not required). I've filed >> https://gitlab.com/esr/reposurgeon/issues/219 anyway with a reduced test >> for this oddity. > > This has now been fixed, so future conversion runs with reposurgeon should > have the automatically-generated .gitignore present until replaced by the > one checked into SVN. (If people don't want automatically-generated > .gitignore files at all, we could always add an option to reposurgeon not > to generate them.)
Removing auto-generated .gitignore files from reposurgeon conversion would allow comparison of git trees vs gcc-pretty and gcc-reparent beyond r195087. So, while we are evaluating the conversion candidates, it is best to disable conversion features that cause hard-to-workaround differences. > > I'll do another GCC conversion run to pick up all the accumulated fixes > and improvements (including many more PR whitelist entries / fixes in > Richard's script), once another ChangeLog-related fix is in. -- Maxim Kuvyrkov https://www.linaro.org
