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

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

Linus Torvalds wrote:

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

H. Peter Anvin wrote:

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

	-hpa

On Mon, 25 Apr 2005, H. Peter Anvin wrote:

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

Linus Torvalds wrote:

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

On Mon, 25 Apr 2005, H. Peter Anvin wrote:

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

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

Linus Torvalds wrote:

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.

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

	-hpa