{"thread":{"id":"297","subject":"Re: git.git object database at kernel.org?","startedAt":"2005-04-24T23:08:12Z","lastAt":"2005-04-26T01:05:45Z","messageCount":7,"participants":["Linus Torvalds","H. Peter Anvin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"1558","messageId":"Pine.LNX.4.58.0504241553580.18901@ppc970.osdl.org","threadId":"297","inReplyTo":"7vhdhvstb2.fsf@assigned-by-dhcp.cox.net","subject":"Re: git.git object database at kernel.org?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-24T23:08:12Z","receivedAt":"2005-04-24T23:08:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nJunio just pointed out that \"convert-cache\" didn't actually handle some of \nthe old-style commits that git itself has (notably, the date changes).\n\nI fixed that, and converted git, so that the dates are now correct in \"git\nlog\" for the early commit entries too.\n\nThis means that all the commit objects in my git tree ended up being\nre-generated: the data itself doesn't change, and none of the tree or blob\nobjects are any different, but since the first \"commit\" changed (the first\nseveral ones, in fact - it was about a week until the date format got\nfixed), the whole chain of commits ends up being different.\n\nThat has almost zero impact _except_ for anybody who merges directly with \nmy tree using git itself. You now have two choices:\n\n - convert your own git tree (probably a good thing, otherwise your old \n commit entries will always be bogus), at which point it should just \n merge fine with mine automatically.\n\n NOTE! The fact that \"mktime()\" seems to depend on the timezone in which \n it is made seems to make this questionable. I had always assumed that \n mktime would take the timezone from the \"struct tm\", and thus be \n reliable, but somebody seems to have shown that that is not the case at \n all!\n\n It's entirely possible that you need to do something stupid like\n\n\tTZ=US/Pacific\n\n before you convert your tree. I wonder if this might also explain the \n problems some people (notably Russell) had at around the conversion..\n\n Anyway, _if_ your conversion was successful and matches mine, you\n should now have a root \"e83c5163316f89bfbde7d9ab23ca2e25604af290\", that\n is reachable from the result of the conversion (check with \"git log\n \"). You should also have as a top (unless you have made changes \n of your own):\n\n\tcommit 3f053897b3445988309d0ae7378944783c34d152\n\ttree f5c350ae39f61486622c84597a507611e62fa6af\n\tparent c6e007b0942a373bbf87fa3e4e11e2d90907de8c\n\tauthor Linus Torvalds Sun Apr 24 22:49:09 2005\n\tcommitter Linus Torvalds Sun Apr 24 22:49:09 2005\n\t\n\t Update \"convert-cache\" to handle git itself.\n\t \n\t The git archives have some old-date-format commits with timezones\n\t that the converter didn't recognize. Also, make it be quiet about\n\t already-converted dates.\n\n If it doesn't match that, you can run \"convert-cache\" (with the\n _original_ head) several times. When you are happy that it's all ok,\n you can \"commit\" the result by writing it to your .git/HEAD file.\n\n - alternatively, if you don't want to convert your thing, you can give a \n \"base commit\" by hand when merging, and select one where the \"tree\" \n object matches in both mine and yours. This isn't something I would \n recommend, but it should work and \"meld\" the two commit chains together \n even though their root entries differ.\n\nSorry about all this, I had totally forgotten that we had old-style dates \nin our git commit history.\n\n\t\t\tLinus\n"},{"id":"1639","messageId":"426D3B01.8060408@zytor.com","threadId":"297","inReplyTo":"Pine.LNX.4.58.0504241553580.18901@ppc970.osdl.org","subject":"Re: git.git object database at kernel.org?","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-04-25T18:46:25Z","receivedAt":"2005-04-25T18:46:25Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> NOTE! The fact that \"mktime()\" seems to depend on the timezone in which \n> it is made seems to make this questionable. I had always assumed that \n> mktime would take the timezone from the \"struct tm\", and thus be \n> reliable, but somebody seems to have shown that that is not the case at \n> all!\n> \n\nNo, mktime() always uses the local time zone. It's the inverse of \nlocaltime(). If you know the timezone offset (e.g. if you have a RFC \n2822-style date) then you're probably better off rolling your own; \notherwise setenv(\"TZ\"); tzset(); mktime(); is of course also doable.\n\n\t-hpa\n"},{"id":"1642","messageId":"426D3F88.9050709@zytor.com","threadId":"297","inReplyTo":"426D3B01.8060408@zytor.com","subject":"Re: git.git object database at kernel.org?","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-04-25T19:05:44Z","receivedAt":"2005-04-25T19:05:44Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"H. Peter Anvin wrote:\n> Linus Torvalds wrote:\n> \n>> NOTE! The fact that \"mktime()\" seems to depend on the timezone in \n>> which it is made seems to make this questionable. I had always \n>> assumed that mktime would take the timezone from the \"struct tm\", \n>> and thus be reliable, but somebody seems to have shown that that is \n>> not the case at all!\n> \n> No, mktime() always uses the local time zone. It's the inverse of \n> localtime(). If you know the timezone offset (e.g. if you have a RFC \n> 2822-style date) then you're probably better off rolling your own; \n> otherwise setenv(\"TZ\"); tzset(); mktime(); is of course also doable.\n> \n\nBTW, curl_getdate() from libcurl is a good multiformat date parser.\n\n\t-hpa\n"},{"id":"1679","messageId":"Pine.LNX.4.58.0504251729080.18901@ppc970.osdl.org","threadId":"297","inReplyTo":"426D3B01.8060408@zytor.com","subject":"Re: git.git object database at kernel.org?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-26T00:32:17Z","receivedAt":"2005-04-26T00:32:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 25 Apr 2005, H. Peter Anvin wrote:\n> \n> No, mktime() always uses the local time zone. It's the inverse of \n> localtime().\n\nNote that this still doesn't make any sense.\n\nA true inverse of \"localtime()\" should still take the GMT offset from\n\"struct tm\", and it would work fine, assuming that localtime() set that\noffset correctly.\n\nSo _I_ think it's incredibly stupid that mktime() looks at the local \ntimezone. \n\nOh, well. Not a big issue except for the date conversion, and since there \nhopefully aren't any old repo's left, we can leave it behind us.\n\n\t\tLinus\n"},{"id":"1683","messageId":"426D8FDF.5050608@zytor.com","threadId":"297","inReplyTo":"Pine.LNX.4.58.0504251729080.18901@ppc970.osdl.org","subject":"Re: git.git object database at kernel.org?","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-04-26T00:48:31Z","receivedAt":"2005-04-26T00:48:31Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Mon, 25 Apr 2005, H. Peter Anvin wrote:\n> \n>>No, mktime() always uses the local time zone. It's the inverse of \n>>localtime().\n> \n> Note that this still doesn't make any sense.\n> \n> A true inverse of \"localtime()\" should still take the GMT offset from\n> \"struct tm\", and it would work fine, assuming that localtime() set that\n> offset correctly.\n> \n> So _I_ think it's incredibly stupid that mktime() looks at the local \n> timezone. \n> \n> Oh, well. Not a big issue except for the date conversion, and since there \n> hopefully aren't any old repo's left, we can leave it behind us.\n> \n\nIt *is* incredibly stupid, but dates back to the fact that a the GMT \noffset field in struct tm is a reasonably recent invention, and a lot of \nold code depended on just stuffing fields in struct tm and calling \nmktime(); they would leave the offset field uninitialized, as opposed to \nsetting it to some well-defined \"I don't know\" value.\n\nWhat totally blows is that if mktime() can't be fixed, that we haven't \nadded mktime_have_offset() or something like that.\n\nOh well. If you have the offset, the algorithm is fully arithmetric and \ndoesn't rely on the zoneinfo system, so it can be trivially implemented. \n And again, curl_gettime() does handle the whole string to time_t \nconversion of the common formats.\n\n\t-hpa\n\n"},{"id":"1685","messageId":"Pine.LNX.4.58.0504251756190.18901@ppc970.osdl.org","threadId":"297","inReplyTo":"426D8FDF.5050608@zytor.com","subject":"Re: git.git object database at kernel.org?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-26T00:58:27Z","receivedAt":"2005-04-26T00:58:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 25 Apr 2005, H. Peter Anvin wrote:\n> \n> Oh well. If you have the offset, the algorithm is fully arithmetric and \n> doesn't rely on the zoneinfo system, so it can be trivially implemented. \n\nYou have a different definition of \"trivial\" than I do. I have not a \nfrigging clue how to handle leap seconds etc ;)\n\n> And again, curl_gettime() does handle the whole string to time_t \n> conversion of the common formats.\n\nI don't doubt you, I just would prefer to not rely on boutique libraries \ntoo much. \n\nYeah, we already use it for http-pull, so I guess it's moot, but at least \nthat felt less like a core command..\n\n\t\tLinus\n"},{"id":"1686","messageId":"426D93E9.10407@zytor.com","threadId":"297","inReplyTo":"Pine.LNX.4.58.0504251756190.18901@ppc970.osdl.org","subject":"Re: git.git object database at kernel.org?","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-04-26T01:05:45Z","receivedAt":"2005-04-26T01:05:45Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Mon, 25 Apr 2005, H. Peter Anvin wrote:\n> \n>>Oh well. If you have the offset, the algorithm is fully arithmetric and \n>>doesn't rely on the zoneinfo system, so it can be trivially implemented. \n> \n> You have a different definition of \"trivial\" than I do. I have not a \n> frigging clue how to handle leap seconds etc ;)\n> \n\nLeap seconds don't exist in the POSIX time_t universe, so they always obey:\n\n\t... + 3600*hour + 60*min + sec\n\n... which means that during a positive leap second, time_t remains \nunchanged for 2 seconds, and for a negative leap second time_t jumps. \nThus, the difference between two time_t doesn't always match the exact \nnumber of seconds between those two points in time.\n\n> \n>> And again, curl_gettime() does handle the whole string to time_t \n>>conversion of the common formats.\n> \n> I don't doubt you, I just would prefer to not rely on boutique libraries \n> too much. \n> \n> Yeah, we already use it for http-pull, so I guess it's moot, but at least \n> that felt less like a core command..\n> \n\nIf we're already using libcurl, we might as well. Otherwise, I'd just \nrip out curl_gettime from the libcurl sources.\n\n\t-hpa\n"}]}