Re: git-fast-import

From: Nicolas Pitre <nico@cam.org>
Date: Feb 6, 2007, 18:53 UTC
Message-ID: <Pine.LNX.4.64.0702061329090.19212@xanadu.home>
In-Reply-To: <Pine.LNX.4.64.0702060913220.8424@woody.linux-foundation.org>

On Tue, 6 Feb 2007, Linus Torvalds wrote:

Show 11 quoted lines

> I'm not so worried about the git date parsing routines (which are fairly 
> solid) as about the fact that absolutely *tons* of people get rfc2822 
> wrong.
> 
> They allow pretty much any half-way valid date, exactly because people 
> don't do rfc2822 right anyway (and because they are also meant to work 
> even if you write the date by hand, like "12:34 2005-06-07").
> 
> Sure, you can still mess up the program that actually generates the data 
> for gfi, and have bugs like that *there*, but at least they'd have to 
> think a bit about it.

Well, exactly because GIT already has fairly solid date parsing routines, and the fact that we needed solid date parsing routines in the first place, exactly because people don't do rfc2822 right anyway, should be a hell of a big clue why we should parse date information for the gfi frontend. Because the date is for sure most likely in a screwed up format already and it is counter productive to have to deal with that in a duplicated piece of code. And the bare reality is that people will just not care to parse it right themselves.

Quoting from the gfi manual:

|A typical frontend for gfi tends to weigh in at approximately 200
|lines of Perl/Python/Ruby code.  Most developers have been able to
|create working importers in just a couple of hours, even though it
|is their first exposure to gfi, and sometimes even to Git.  This is
|an ideal situation, given that most conversion tools are throw-away
|(use once, and never look back).

This is therefore a damn good idea if gfi can make things right out of crap because frontends will not get much attention after the first "hey it works" level. And the GIT date format, albeit being perfectly unambigous, is not inline with the statement above.

With the GIT date format a conversion _will_ be necessary in the frontend, while if gfi shove it to parse_date() instead then no conversion is even likely to be needed by the frontend. I'd much prefer if frontend writers didn't have to care (and most probably manage to botch it if they have to) about date conversion. We even botched it a few times ourselves despite the fact that we're damn good.

And because our date parsing code is damn good (hey we're just damn good aren't we?) I would bet that there will be much less conversion errors if gfi used parse_date() on provided data than if the frontend tries to parse the date itself. This is wat we feed email submission through everyday anyway, so we must trust it to do a good job for imports as well.

Nicolas