On Mon, 25 Nov 2019, Eric S. Raymond wrote: > I knew there was a problem with those, but I have not diagnosed it > yet. I know generally where it has to be and think it will be > relatively easy to clean up once I've dealt with the more pressing > issues. > > Please file issues about these bugs so I can track then. > > On the first one, it would be helpful if you could list some tags > that these match expressions fail to pick up from as early as > possible. Shortening the leading segment I need to load speeds up > my test cycle significantly,
Comment added on issue 165 pointing to specific tags that wrongly failed to get deleted. Another comment added on issue 165 regarding cases where a tag deletion command deleted only a subset of the matching tags, since it seems plausible the underlying issue could be the same. Issue 166 filed for the deleted-r branches and tags staying around. Issue 167 filed for the loss of the changes from the commit for the gcc-2_95_3 tag. In all cases, my testing includes changes from my merge requests for the gcc-conversion repository, rather than being based on the unmodified upstream state of that repository, but I don't have any reason to think these bugs depend on those changes. A further note: in a previous run of the conversion I didn't see any emptycommit-* tags. In my most recent conversion run, I see 4070 such tags. How do I tell reposurgeon never to create such tags? Or should I add a tag deletion command for them in gcc.lift, once tag deletion is working reliably? -- Joseph S. Myers jos...@codesourcery.com
