Re: git-fast-import

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 6 Feb 2007, Shawn O. Pearce wrote:
> > Nicolas Pitre <nico@xxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]