git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git-fast-import

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Feb 6, 2007, 16:35 UTC
Message-ID
<Pine.LNX.4.64.0702060829310.8424@woody.linux-foundation.org>
In-Reply-To
<20070206054808.GA10508@spearce.org>
On Tue, 6 Feb 2007, Shawn O. Pearce wrote:
Show 10 quoted lines
> 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.

The original (first seven days) date format inside git objects was rfc2822, and it was *horrible*. Not only does it take time to parse, people get it constantly wrong, and it's ambiguous what summer-time means etc. It's basically impossible to get anything that is totally repeatable from it, and you have to be so lax as to effectively accept even buggy input. And yes, buggy input exists.

So I would strongly suggest that gfi keeps to the standard git date format which is easy to parse, and totally unambiguous. Yes, you can get it wrong, but at least then it's very clear *who* gets it wrong: it's whatever feeds data to gfi. If gfi accepts a "soft" format, you get into all these gray areas of whether you want to be strictly rfc2822 only, or whether you actually want to accept stuff that everybody accepts (including the git date functions, that try very hard to turn anything sensible into a date). And DST. And odd timezone names, etc etc.

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.

		Linus
Previous: Shawn O. PearceNext: Shawn O. Pearce
Message 5 of 49 in “git-fast-import”
  1. Shawn O. PearceFeb 6, 2007
  2. Nicolas PitreFeb 6, 2007
  3. Nicolas PitreFeb 6, 2007
  4. Shawn O. PearceFeb 6, 2007
  5. Linus TorvaldsFeb 6, 2007
  6. Shawn O. PearceFeb 6, 2007
  7. Linus TorvaldsFeb 6, 2007
  8. Nicolas PitreFeb 6, 2007
  9. Shawn O. PearceFeb 6, 2007
  10. Nicolas PitreFeb 6, 2007
  11. Shawn O. PearceFeb 6, 2007
  12. Nicolas PitreFeb 6, 2007
  13. David WoodhouseFeb 7, 2007
  14. Aneesh Kumar K.VFeb 6, 2007
  15. Shawn O. PearceFeb 6, 2007
  16. Daniel BarkalowFeb 7, 2007
  17. Karl HasselströmFeb 7, 2007
  18. Johannes SchindelinFeb 7, 2007
  19. Shawn O. PearceFeb 7, 2007
  20. Johannes SchindelinFeb 7, 2007
  21. Shawn O. PearceFeb 8, 2007
  22. Linus TorvaldsFeb 8, 2007
  23. Shawn O. PearceFeb 8, 2007
  24. Karl HasselströmFeb 9, 2007
  25. Linus TorvaldsFeb 9, 2007
  26. Raimund BauerFeb 7, 2007
  27. David WoodhouseFeb 7, 2007
  28. Andy ParkinsFeb 6, 2007
  29. Shawn O. PearceFeb 6, 2007
  30. Linus TorvaldsFeb 6, 2007
  31. Shawn O. PearceFeb 6, 2007
  32. Linus TorvaldsFeb 6, 2007
  33. Horst H. von BrandFeb 7, 2007
  34. Linus TorvaldsFeb 7, 2007
  35. Shawn O. PearceFeb 7, 2007
  36. Karl HasselströmFeb 7, 2007
  37. Horst H. von BrandFeb 7, 2007
  38. Jakub NarebskiFeb 7, 2007
  39. Linus TorvaldsFeb 7, 2007
  40. Johannes SchindelinFeb 8, 2007
  41. Shawn O. PearceFeb 7, 2007
  42. Daniel BarkalowFeb 7, 2007
  43. Jakub NarebskiFeb 6, 2007
  44. Shawn O. PearceFeb 6, 2007
  45. Jakub NarebskiFeb 6, 2007
  46. Shawn O. PearceFeb 6, 2007
  47. Alex RiesenFeb 6, 2007
  48. Shawn O. PearceFeb 6, 2007
  49. Alex RiesenFeb 6, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.