On Wed, 2019-12-18 at 13:50 -0600, Segher Boessenkool wrote: > On Wed, Dec 18, 2019 at 11:07:11AM -0700, Jeff Law wrote: > > > That isn't what I said. I said that freshly constructed complex software > > > will have more and deeper errors than stupid simple scripts do (or I > > > implied that at least, maybe it wasn't clear). And I only say this > > > because the opposite was claimed, which is laughable imnsho. > > But it's not that freshly constructed, at least not in my mind. All > > the experience ESR has from the python implementation carries to the Go > > implementation. > > What, writing code in Python made him learn Go? ?!? What does that question have to do with anything?
My point is the experience of writing reposurgeon and in particular being intimately familiar with what does on under the hood inside CVS, SVN and GIT has great value, particularly in converting a large repo like ours that has warts from the CVS and SVN days as well as warts from the CVS->SVN conversion. > > And the "simple scripts" argument dismisses the fact that those scripts > > are built on top of complex software. It just doesn't hold water IMHO. > > This is the Unix philosophy though! But your comment doesn't address the fact that in both cases, reposurgeon and Maxim's scripts, there's complex code involved. In Maxim's case it's just under the covers. Ultimately I don't care about the Unix philosophy. I'm pragmatic. If reposurgeon gives us a better conversion, and it sounds very much like it already does, then the fact that it doesn't follow the Unix philosophy is irrelevant to me. > > > Where I think we could have done better would have been to get more > > concrete detail from ESR about the problems with git-svn. That was > > never forthcoming and it's a disappointment. > > Yes. And as far as I can see you can wait forever for it. Oh well, we > have a lot of experience in waiting. Umm, no, I'm not suggesting we wait in any way at all. Based on what I've heard from Joseph, I'd vote today to go with reposurgeon as soon as it's convenient for the people doing the conversion and our development cycle. This highlights one big issue that we have as a project. Specifically that we don't have a clear cut way to make these kinds of technical decisions when there isn't unanimous consent. > > > I do think we've gotten some details about the "scar tissue" from the > > cvs->svn transition as well as some of our branch problems. It's my > > understanding reposurgeon cleans this up significantly whereas Maxim's > > scripts don't touch this stuff IIUC. > > They do, I think? This was easy to do, too: > git://git.linaro.org/people/maxim-kuvyrkov/gcc-reparent.git/ Good. Thanks for clarifying. > > > > > > As long as the original commit message is kept, verbatim, and you only > > > > > add a new summary line, all is fine. If not -> nope, not okay. > > > > Sorry, have to disagree here. I think what Richard has done is a > > > > significant step forward. > > > > > > We talked about it for days, and as far as I understand it Richard agreed. > > When Richard and I spoke we generally agreed that we felt a reposurgeon > > conversion, if it could be made to work was the preferred solution, > > followed by Maxim's approach and lastly the existing git-svn mirror. > > If I'm mis-representing Richard's position I hope he'll chime in and > > correct the record. > > This is just about the "we should not try to change the commit message", > and Joseph confirmed that is what is done now. So that is all fine. OK jeff
