Hi! On Wed, Dec 18, 2019 at 01:43:19PM -0700, Jeff Law wrote: > 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?
There is a lot more needed to write reliable programs than just domain knowledge. git-svn is used for this exact purpose (converting svn commits to git commits) millions of times per day, for I-don't-know- how long already. Yes, I trust that better than newly written code. The point is completely moot if we actually verify and compare the resulting trees, of course. > 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. Exactly the same here! But we need to look at the actual candidate conversions to determine this. Not just say "I like X better than Y". That is at best subjective; we can do better than that. > > > 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. And neither am I. I don't wait for things I do not expect to happen. And I want a Git conversion soon, not wait more years for it. > 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. This isn't a technical decision really. Both candidate conversions are perfect technically already (or will be soon). All that is left is a) aesthetics, so everyone wants something else; b) some people are dead set against falsifying history (including me), while other people think something that looks slightly better is more important; and c) what tags and branches do we not carry over from svn at all? We'll keep the svn repo around as well, anyway. If Joseph and Richard agree a candidate is good, then I will agree as well. All that can be left is nit-picking, and that is not worth it anyway: the repository will not be perfect no matter what, people have made mistakes, we can only fix some superficial ones. Some of those are practically important (because they are annoying), but most are not. Segher
