Re: git-fast-import

From: Shawn O. Pearce <spearce@spearce.org>
Date: Feb 6, 2007, 16:56 UTC
Message-ID: <20070206165630.GB4949@spearce.org>
In-Reply-To: <Pine.LNX.4.64.0702060829310.8424@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> wrote:

Show 13 quoted lines

> On Tue, 6 Feb 2007, Shawn O. Pearce wrote:
> > Nicolas Pitre <nico@cam.org> wrote:
> > > I think this is quite error prone, demonstrated by the fact that we 
> > > screwed that up ourselves on a few occasions.  I think that the frontend 
> > > should be relieved from this by letting it provide the time of change in 
> > > a more natural format amongst all possible ones(like RFC2822 for 
> > > example) and gfi should simply give it to parse_date().
> > 
> > This is a really good point.  Its a little bit of work to switch
> > to parse_date(); I'll try to get it done tomorrow night.
> 
> Actually, I disagree. We've traditionally have had _less_ bugs with the 
> pure integer format than we ever had with RFC2822 format.

Hmm.  Actually I think it depends on the source data.  :-)

If the source is only supplying RFC2822 date format and is reliable in its formatting of such, having gfi parse that rather than the frontend is probably more reliable. (Git already has a well tested date parsing routine.) But if the source is easily able to get a time_t then that is just as easily formatted out to gfi, and reading that without error is child's play.

After reading your email I'm now contemplating making this a command
line flag, like `--date-format=rfc2822`, so a frontend could ask
gfi to use parse_date() and whatever error that might bring, or
stick with the pure integer format.

> Having a hard format, set in stone, and totally unambiguous, is really a 
> good thing. It actually ends up resulting in fewer bugs in the end, 
> because it just makes sure that everybody is on the same page.

Which is why gfi is very strict about its handling of whitespace. It assumes *exactly* one space between input fields, or *exactly* one LF between commands. Anything else is assumed to be part of the next field. If spaces show up in the imported data, its the frontend that is sending stuff incorrectly.

Right now however gfi is not validating the author or committer command arguments. At all. Which means that although the documentation says the format must be such-and-such, gfi doesn't care. Whatever comes in on the `author` or `committer` line is copied verbatim into the commit object. gfi probably should at least verify that the timestamp part of the line actually contains digits. :)

-- 
Shawn.