This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Proposal for the transition timetable for the move to GIT


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]