On Dec 26, 2019, "Eric S. Raymond" <e...@thyrsus.com> wrote:
> Alexandre Oliva <ol...@gnu.org>: >> On Dec 25, 2019, "Eric S. Raymond" <e...@thyrsus.com> wrote: >> >> > Reposurgeon has a reparent command. If you have determined that a >> > branch is detached or has an incorrect attachment point, patching the >> > metadata of the root node to fix that is very easy. >> >> Thanks, I see how that can enable a missed branch to be converted and >> added incrementally to a converted repo even after it went live, at >> least as long as there aren't subsequent merges from a converted branch >> to the missed one. I don't quite see how this helps if there are, >> though. > There's also a command for cutting parent links, ifvthat helps. I don't see that it does (help). Incremental conversion of a missed branch should include the very same parent links that the conversion of the entire repo would, just linking to the proper commits in the adopted conversion. git-svn can do that incrementally, after the fact; I'm not sure whether either conversion tool we're contemplating does, but being able to undertake such recovery seems like a desirable feature to me. > repotool compare does that, and there's a production in the conversion > makefile that applies it. > As Joseph says in anotyer reply, he's already doing a lot of the > verifications you are suggesting. >From what I read, he's doing verifications against SVN. What I'm suggesting, at this final stage, is for us to do verify one git converted repo against the other. Since both claim to be nearing readiness for adoption, I gather it's the time for both to be comparing with each other (which should be far more efficient than comparing with SVN) and attempting to narrow down on differences and converge, so that the community can choose one repo or another on the actual merits of the converted repositories (e.g. slight policy differences in metadata conversion), rather than on allegations by developers of either conversion tool about the reliability of the tool used by the each other. Maxim appears to be doing so and finding (easy-to-fix) problems in the reposurgeon conversion; it would be nice for reposurgeon folks to reciprocate and maybe even point out problems in the gcc-pretty conversion, if they can find any, otherwise the allegations of unsuitability of the tools would have to be taken on blind faith. I wouldn't like the community to have to decide based on blind faith, rather than hard data. I'd much rather we had two great, maybe even equivalent repos to choose from, possibly with a coin toss if they're close enough, than pick one over the other on unsubstantiated faith. It appears to me that this final stage of collaboration and coopetition, namely comparing the converted repos proposed for adoption and aiming at convergence, is in the best interest of our community, even if seemingly at odds with the promotion of either conversion tool. I hope we can set aside these slight conflicts of interest, and do what's best for the community. -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Free Software Evangelist Stallman was right, but he's left :( GNU Toolchain Engineer FSMatrix: It was he who freed the first of us FSF & FSFLA board member The Savior shall return (true);
