Re: git.git object database at kernel.org?

Re: git.git object database at kernel.org?

[Linus Torvalds]

Junio just pointed out that "convert-cache" didn't actually handle some of 
the old-style commits that git itself has (notably, the date changes).

I fixed that, and converted git, so that the dates are now correct in "git
log" for the early commit entries too.

This means that all the commit objects in my git tree ended up being
re-generated: the data itself doesn't change, and none of the tree or blob
objects are any different, but since the first "commit" changed (the first
several ones, in fact - it was about a week until the date format got
fixed), the whole chain of commits ends up being different.

That has almost zero impact _except_ for anybody who merges directly with 
my tree using git itself. You now have two choices:

 - convert your own git tree (probably a good thing, otherwise your old 
   commit entries will always be bogus), at which point it should just 
   merge fine with mine automatically.

   NOTE! The fact that "mktime()" seems to depend on the timezone in which 
   it is made seems to make this questionable. I had always assumed that 
   mktime would take the timezone from the "struct tm", and thus be 
   reliable, but somebody seems to have shown that that is not the case at 
   all!

   It's entirely possible that you need to do something stupid like

	TZ=US/Pacific

   before you convert your tree. I wonder if this might also explain the 
   problems some people (notably Russell) had at around the conversion..

   Anyway, _if_ your conversion was successful and matches mine, you
   should now have a root "e83c5163316f89bfbde7d9ab23ca2e25604af290", that
   is reachable from the result of the conversion (check with "git log
   <result>"). You should also have as a top (unless you have made changes 
   of your own):

	commit 3f053897b3445988309d0ae7378944783c34d152
	tree f5c350ae39f61486622c84597a507611e62fa6af
	parent c6e007b0942a373bbf87fa3e4e11e2d90907de8c
	author Linus Torvalds <torvalds@ppc970.osdl.org> Sun Apr 24 22:49:09  2005
	committer Linus Torvalds <torvalds@ppc970.osdl.org> Sun Apr 24 22:49:09  2005
	
	  Update "convert-cache" to handle git itself.
	  
	  The git archives have some old-date-format commits with timezones
	  that the converter didn't recognize. Also, make it be quiet about
	  already-converted dates.

   If it doesn't match that, you can run "convert-cache" (with the
   _original_ head) several times. When you are happy that it's all ok,
   you can "commit" the result by writing it to your .git/HEAD file.

 - alternatively, if you don't want to convert your thing, you can give a 
   "base commit" by hand when merging, and select one where the "tree"  
   object matches in both mine and yours. This isn't something I would 
   recommend, but it should work and "meld" the two commit chains together 
   even though their root entries differ.

Sorry about all this, I had totally forgotten that we had old-style dates 
in our git commit history.

			Linus

Re: git.git object database at kernel.org?

[H. Peter Anvin]

Linus Torvalds wrote:
> 
>    NOTE! The fact that "mktime()" seems to depend on the timezone in which 
>    it is made seems to make this questionable. I had always assumed that 
>    mktime would take the timezone from the "struct tm", and thus be 
>    reliable, but somebody seems to have shown that that is not the case at 
>    all!
> 

No, mktime() always uses the local time zone.  It's the inverse of 
localtime().  If you know the timezone offset (e.g. if you have a RFC 
2822-style date) then you're probably better off rolling your own; 
otherwise setenv("TZ"); tzset(); mktime(); is of course also doable.

	-hpa

Re: git.git object database at kernel.org?

[H. Peter Anvin]

H. Peter Anvin wrote:
> Linus Torvalds wrote:
> 
>>    NOTE! The fact that "mktime()" seems to depend on the timezone in 
>> which    it is made seems to make this questionable. I had always 
>> assumed that    mktime would take the timezone from the "struct tm", 
>> and thus be    reliable, but somebody seems to have shown that that is 
>> not the case at    all!
> 
> No, mktime() always uses the local time zone.  It's the inverse of 
> localtime().  If you know the timezone offset (e.g. if you have a RFC 
> 2822-style date) then you're probably better off rolling your own; 
> otherwise setenv("TZ"); tzset(); mktime(); is of course also doable.
> 

BTW, curl_getdate() from libcurl is a good multiformat date parser.

	-hpa

Re: git.git object database at kernel.org?

[Linus Torvalds]

On Mon, 25 Apr 2005, H. Peter Anvin wrote:
> 
> No, mktime() always uses the local time zone.  It's the inverse of 
> localtime().

Note that this still doesn't make any sense.

A true inverse of "localtime()" should still take the GMT offset from
"struct tm", and it would work fine, assuming that localtime() set that
offset correctly.

So _I_ think it's incredibly stupid that mktime() looks at the local 
timezone. 

Oh, well.  Not a big issue except for the date conversion, and since there 
hopefully aren't any old repo's left, we can leave it behind us.

		Linus

Re: git.git object database at kernel.org?

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> On Mon, 25 Apr 2005, H. Peter Anvin wrote:
> 
>>No, mktime() always uses the local time zone.  It's the inverse of 
>>localtime().
> 
> Note that this still doesn't make any sense.
> 
> A true inverse of "localtime()" should still take the GMT offset from
> "struct tm", and it would work fine, assuming that localtime() set that
> offset correctly.
> 
> So _I_ think it's incredibly stupid that mktime() looks at the local 
> timezone. 
> 
> Oh, well.  Not a big issue except for the date conversion, and since there 
> hopefully aren't any old repo's left, we can leave it behind us.
> 

It *is* incredibly stupid, but dates back to the fact that a the GMT 
offset field in struct tm is a reasonably recent invention, and a lot of 
old code depended on just stuffing fields in struct tm and calling 
mktime(); they would leave the offset field uninitialized, as opposed to 
setting it to some well-defined "I don't know" value.

What totally blows is that if mktime() can't be fixed, that we haven't 
added mktime_have_offset() or something like that.

Oh well.  If you have the offset, the algorithm is fully arithmetric and 
doesn't rely on the zoneinfo system, so it can be trivially implemented. 
   And again, curl_gettime() does handle the whole string to time_t 
conversion of the common formats.

	-hpa

Re: git.git object database at kernel.org?

[Linus Torvalds]

On Mon, 25 Apr 2005, H. Peter Anvin wrote:
> 
> Oh well.  If you have the offset, the algorithm is fully arithmetric and 
> doesn't rely on the zoneinfo system, so it can be trivially implemented. 

You have a different definition of "trivial" than I do. I have not a 
frigging clue how to handle leap seconds etc ;)

>    And again, curl_gettime() does handle the whole string to time_t 
> conversion of the common formats.

I don't doubt you, I just would prefer to not rely on boutique libraries 
too much. 

Yeah, we already use it for http-pull, so I guess it's moot, but at least 
that felt less like a core command..

		Linus

Re: git.git object database at kernel.org?

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> On Mon, 25 Apr 2005, H. Peter Anvin wrote:
> 
>>Oh well.  If you have the offset, the algorithm is fully arithmetric and 
>>doesn't rely on the zoneinfo system, so it can be trivially implemented. 
> 
> You have a different definition of "trivial" than I do. I have not a 
> frigging clue how to handle leap seconds etc ;)
> 

Leap seconds don't exist in the POSIX time_t universe, so they always obey:

	... + 3600*hour + 60*min + sec

... which means that during a positive leap second, time_t remains 
unchanged for 2 seconds, and for a negative leap second time_t jumps. 
Thus, the difference between two time_t doesn't always match the exact 
number of seconds between those two points in time.

> 
>>   And again, curl_gettime() does handle the whole string to time_t 
>>conversion of the common formats.
> 
> I don't doubt you, I just would prefer to not rely on boutique libraries 
> too much. 
> 
> Yeah, we already use it for http-pull, so I guess it's moot, but at least 
> that felt less like a core command..
> 

If we're already using libcurl, we might as well.  Otherwise, I'd just 
rip out curl_gettime from the libcurl sources.

	-hpa