{"thread":{"id":"42670","subject":"unable to pull from remote if commit date is in the future","startedAt":"2016-06-20T18:42:07Z","lastAt":"2016-06-20T20:35:26Z","messageCount":10,"participants":["Norbert Kiesel","Stefan Beller","Jeff King","Eric Deplagne","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"289690","messageId":"CAM+g_NswH8fd8aFPEHfSLYnZWptNU2GX=xTWpehzjTJfJM_GfQ@mail.gmail.com","threadId":"42670","inReplyTo":null,"subject":"unable to pull from remote if commit date is in the future","fromName":"Norbert Kiesel","fromEmail":"nkiesel@gmail.com","sentAt":"2016-06-20T18:41:40Z","receivedAt":"2016-06-20T18:42:07Z","isPatch":false,"sender":{"key":"nkiesel@gmail.com","avatar":null},"body":"Hi,\n\nI'm following an upstream repo on github. Today morning I saw a new\ncommit there, but a `git pull` in my clone did not fetch it and\ninstead said \"Already up-to-date.\". On closer inspection, github\nreports commit time as 2152-06-19. The same project has some other\ncommits with commit time in the future that were fetched. My guess is\nthat happened when those commits got a child with commit date in the\npast.\n\nIs there any way to force git pulling that request? (Perhaps I should\ntry to tell git that it's really 2152?)\n\nFor the record: the faulty commit is\nhttps://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf\n"},{"id":"289691","messageId":"CAM+g_NtNAWpLkbErL5-BUyH_3X4rYGfZwO0o-Hfu8zyam8pw7Q@mail.gmail.com","threadId":"42670","inReplyTo":"CAGZ79kZL-ZY_0hZx9uA-ObPvMiD+EWvJYQa+OfCeQe2RLOPECA@mail.gmail.com","subject":"Re: unable to pull from remote if commit date is in the future","fromName":"Norbert Kiesel","fromEmail":"nkiesel@gmail.com","sentAt":"2016-06-20T19:05:07Z","receivedAt":"2016-06-20T19:06:06Z","isPatch":false,"sender":{"key":"nkiesel@gmail.com","avatar":null},"body":"Hmm. On closer inspection that commit 23c07cc that github shows with\ndate 2152-06-19 is already in my local branch. I got confused because\nlocally it is shown with a different date: `git log -1 --format='%ci'\n23c07cc` shows \"2106-02-07 06:28:56 -40643156\" which is invalid.\n\nMy system is running Debian unstable 64bit. Is git using the time\nrendering methods from the C library (glibc 2.22-12)?\n\nOn Mon, Jun 20, 2016 at 11:46 AM, Stefan Beller wrote:\n> On Mon, Jun 20, 2016 at 11:41 AM, Norbert Kiesel wrote:\n>> Hi,\n>>\n>> I'm following an upstream repo on github. Today morning I saw a new\n>> commit there, but a `git pull` in my clone did not fetch it and\n>> instead said \"Already up-to-date.\". On closer inspection, github\n>> reports commit time as 2152-06-19. The same project has some other\n>> commits with commit time in the future that were fetched. My guess is\n>> that happened when those commits got a child with commit date in the\n>> past.\n>\n> git-pull doesn't care about the commit/author date/time at all.\n>\n> All it takes into consideration\n> is the graph structure of the commits on the local and the remote branch,\n> i.e. Are there any commits on the remote branch that are not part of the local\n> branch history?\n>\n>\n>>\n>> Is there any way to force git pulling that request? (Perhaps I should\n>> try to tell git that it's really 2152?)\n>\n> You need to see if that commit is part of the history of the\n> remote branch you pulled.\n>\n>>\n>> For the record: the faulty commit is\n>> https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"289693","messageId":"CAGZ79kZL-ZY_0hZx9uA-ObPvMiD+EWvJYQa+OfCeQe2RLOPECA@mail.gmail.com","threadId":"42670","inReplyTo":"CAM+g_NswH8fd8aFPEHfSLYnZWptNU2GX=xTWpehzjTJfJM_GfQ@mail.gmail.com","subject":"Re: unable to pull from remote if commit date is in the future","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-06-20T18:46:07Z","receivedAt":"2016-06-20T19:14:53Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Jun 20, 2016 at 11:41 AM, Norbert Kiesel wrote:\n> Hi,\n>\n> I'm following an upstream repo on github. Today morning I saw a new\n> commit there, but a `git pull` in my clone did not fetch it and\n> instead said \"Already up-to-date.\". On closer inspection, github\n> reports commit time as 2152-06-19. The same project has some other\n> commits with commit time in the future that were fetched. My guess is\n> that happened when those commits got a child with commit date in the\n> past.\n\ngit-pull doesn't care about the commit/author date/time at all.\n\nAll it takes into consideration\nis the graph structure of the commits on the local and the remote branch,\ni.e. Are there any commits on the remote branch that are not part of the local\nbranch history?\n\n\n>\n> Is there any way to force git pulling that request? (Perhaps I should\n> try to tell git that it's really 2152?)\n\nYou need to see if that commit is part of the history of the\nremote branch you pulled.\n\n>\n> For the record: the faulty commit is\n> https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"289697","messageId":"20160620193928.GA3631@sigill.intra.peff.net","threadId":"42670","inReplyTo":"CAM+g_NtNAWpLkbErL5-BUyH_3X4rYGfZwO0o-Hfu8zyam8pw7Q@mail.gmail.com","subject":"Re: unable to pull from remote if commit date is in the future","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-06-20T19:39:28Z","receivedAt":"2016-06-20T19:40:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote:\n\n> Hmm. On closer inspection that commit 23c07cc that github shows with\n> date 2152-06-19 is already in my local branch. I got confused because\n> locally it is shown with a different date: `git log -1 --format='%ci'\n> 23c07cc` shows \"2106-02-07 06:28:56 -40643156\" which is invalid.\n> \n> My system is running Debian unstable 64bit. Is git using the time\n> rendering methods from the C library (glibc 2.22-12)?\n\nNo, git's time code is (mostly) internal routines. Can you show us the\noutput of:\n\n git cat-file commit 23c07cc | egrep '^author|committer'\n\nNote also that some interfaces (like \"git log\", and GitHub) will show\nthe author date by default, which might be different than the committer\ndate. The \"-40643156\" timezone definitely looks suspicious, though. I'm\ncurious if it is bad handling in the time code, or if the commit has\ncorrupt ident lines.\n\n-Peff\n"},{"id":"289698","messageId":"CAM+g_NsxQrHedp0BNTjMP9H8XfaK7XaYcGdSSkc=BW4QigVixw@mail.gmail.com","threadId":"42670","inReplyTo":"20160620193928.GA3631@sigill.intra.peff.net","subject":"Re: unable to pull from remote if commit date is in the future","fromName":"Norbert Kiesel","fromEmail":"nkiesel@gmail.com","sentAt":"2016-06-20T19:45:13Z","receivedAt":"2016-06-20T19:45:18Z","isPatch":false,"sender":{"key":"nkiesel@gmail.com","avatar":null},"body":"On Mon, Jun 20, 2016 at 12:39 PM, Jeff King wrote:\n> git cat-file commit 23c07cc | egrep '^author|committer'\n\nauthor Sean D'Epagnier 5758122296 -40643156\ncommitter Sean D'Epagnier 5758122296 -40643156\n\ndate --date='@5758122296' returns \"Mon Jun 19 15:24:56 PDT 2152\" which\nis what is shown by github.\n"},{"id":"289699","messageId":"20160620194648.GB3631@sigill.intra.peff.net","threadId":"42670","inReplyTo":"20160620193928.GA3631@sigill.intra.peff.net","subject":"Re: unable to pull from remote if commit date is in the future","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-06-20T19:46:49Z","receivedAt":"2016-06-20T19:47:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 20, 2016 at 03:39:28PM -0400, Jeff King wrote:\n\n> On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote:\n> \n> > Hmm. On closer inspection that commit 23c07cc that github shows with\n> > date 2152-06-19 is already in my local branch. I got confused because\n> > locally it is shown with a different date: `git log -1 --format='%ci'\n> > 23c07cc` shows \"2106-02-07 06:28:56 -40643156\" which is invalid.\n> > \n> > My system is running Debian unstable 64bit. Is git using the time\n> > rendering methods from the C library (glibc 2.22-12)?\n> \n> No, git's time code is (mostly) internal routines. Can you show us the\n> output of:\n> \n> git cat-file commit 23c07cc | egrep '^author|committer'\n> \n> Note also that some interfaces (like \"git log\", and GitHub) will show\n> the author date by default, which might be different than the committer\n> date. The \"-40643156\" timezone definitely looks suspicious, though. I'm\n> curious if it is bad handling in the time code, or if the commit has\n> corrupt ident lines.\n\nActually, I just noticed in your earlier message a link to the public\nGitHub repository.\n\nSo to answer my own questions:\n\n $ git cat-file commit 23c07cc | egrep '^author|committer'\n author Sean D'Epagnier 5758122296 -40643156\n committer Sean D'Epagnier 5758122296 -40643156\n\nYes, the timezone really is that ridiculous value. No, the author and\ncommitter aren't different. According to GNU date, the correct timestamp\nis actually in 2152. Offhand, I'd guess that the timestamp exceeding\n2^32 is getting converted somewhere inside git to a bogus value, and\nthat's how we end up with 2106.\n\n-Peff\n"},{"id":"289701","messageId":"20160620194947.GE24553@mail.eric.deplagne.name","threadId":"42670","inReplyTo":"20160620193928.GA3631@sigill.intra.peff.net","subject":"Re: unable to pull from remote if commit date is in the future","fromName":"Eric Deplagne","fromEmail":"eric@deplagne.name","sentAt":"2016-06-20T19:49:47Z","receivedAt":"2016-06-20T19:50:54Z","isPatch":false,"sender":{"key":"eric@deplagne.name","avatar":null},"body":"On Mon, 20 Jun 2016 15:39:28 -0400, Jeff King wrote:\n> On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote:\n> \n> > Hmm. On closer inspection that commit 23c07cc that github shows with\n> > date 2152-06-19 is already in my local branch. I got confused because\n> > locally it is shown with a different date: `git log -1 --format='%ci'\n> > 23c07cc` shows \"2106-02-07 06:28:56 -40643156\" which is invalid.\n> > \n> > My system is running Debian unstable 64bit. Is git using the time\n> > rendering methods from the C library (glibc 2.22-12)?\n> \n> No, git's time code is (mostly) internal routines. Can you show us the\n> output of:\n> \n> git cat-file commit 23c07cc | egrep '^author|committer'\n> \n> Note also that some interfaces (like \"git log\", and GitHub) will show\n> the author date by default, which might be different than the committer\n> date. The \"-40643156\" timezone definitely looks suspicious, though. I'm\n> curious if it is bad handling in the time code, or if the commit has\n> corrupt ident lines.\n> \n> -Peff\n\n 2106 is the year of unsigned 32-bit unix time bug, would there be any relation ?\n\n-- \n Eric Deplagne\n"},{"id":"289702","messageId":"20160620200011.GC3631@sigill.intra.peff.net","threadId":"42670","inReplyTo":"20160620194648.GB3631@sigill.intra.peff.net","subject":"Re: unable to pull from remote if commit date is in the future","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-06-20T20:00:12Z","receivedAt":"2016-06-20T20:01:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 20, 2016 at 03:46:49PM -0400, Jeff King wrote:\n\n> So to answer my own questions:\n> \n> $ git cat-file commit 23c07cc | egrep '^author|committer'\n> author Sean D'Epagnier 5758122296 -40643156\n> committer Sean D'Epagnier 5758122296 -40643156\n> \n> Yes, the timezone really is that ridiculous value. No, the author and\n> committer aren't different. According to GNU date, the correct timestamp\n> is actually in 2152. Offhand, I'd guess that the timestamp exceeding\n> 2^32 is getting converted somewhere inside git to a bogus value, and\n> that's how we end up with 2106.\n\nAh, nope. Everything is working as designed.\n\n5758122296 _is_ in 2152, but that's before we apply the author's\ntimezone offset. :)\n\nTimezones are supposed to be [+-]HHMM. So the -40643156 timezone is\nparsed as -406431 hours, 56 minutes. Which is about 46 years. Hence git\nprinting 2106.\n\nYou _should_ be able to get the right answer by asking git for\n--date=local, but it doesn't seem to work. Looks like it is because our\ntm_to_time_t hits this code:\n\n if (year < 0 || year > 129) /* algo only works for 1970-2099 */\n\treturn -1;\n\nand the caller does not actually check the error. The resulting timezone\nis the screwed-up -40643156, which is perhaps how it got into the commit\nin the first place.\n\n-Peff\n"},{"id":"289703","messageId":"20160620200209.GD3631@sigill.intra.peff.net","threadId":"42670","inReplyTo":"20160620194947.GE24553@mail.eric.deplagne.name","subject":"Re: unable to pull from remote if commit date is in the future","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-06-20T20:02:09Z","receivedAt":"2016-06-20T20:10:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 20, 2016 at 09:49:47PM +0200, Eric Deplagne wrote:\n\n> On Mon, 20 Jun 2016 15:39:28 -0400, Jeff King wrote:\n> > On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote:\n> > \n> > > Hmm. On closer inspection that commit 23c07cc that github shows with\n> > > date 2152-06-19 is already in my local branch. I got confused because\n> > > locally it is shown with a different date: `git log -1 --format='%ci'\n> > > 23c07cc` shows \"2106-02-07 06:28:56 -40643156\" which is invalid.\n> > > \n> > > My system is running Debian unstable 64bit. Is git using the time\n> > > rendering methods from the C library (glibc 2.22-12)?\n> > \n> > No, git's time code is (mostly) internal routines. Can you show us the\n> > output of:\n> > \n> > git cat-file commit 23c07cc | egrep '^author|committer'\n> > \n> > Note also that some interfaces (like \"git log\", and GitHub) will show\n> > the author date by default, which might be different than the committer\n> > date. The \"-40643156\" timezone definitely looks suspicious, though. I'm\n> > curious if it is bad handling in the time code, or if the commit has\n> > corrupt ident lines.\n> > \n> > -Peff\n> \n> 2106 is the year of unsigned 32-bit unix time bug, would there be any relation ?\n\nIn an extremely roundabout way, yes. That -40643156 time zone really is\n\"minus 46 years\", but it was generated by _different_ code trying to\ncompute the author timezone on the fly and using a stray \"-1\". So I\nsuspect that no matter what time you ask for in the year 2152 (or\nlater), the same process would end up with the 2106 time, as the\ntimezone is custom-computed to end up back at the same error point.\n\n-Peff\n"},{"id":"289704","messageId":"87porbip12.fsf@linux-m68k.org","threadId":"42670","inReplyTo":"CAM+g_NswH8fd8aFPEHfSLYnZWptNU2GX=xTWpehzjTJfJM_GfQ@mail.gmail.com","subject":"Re: unable to pull from remote if commit date is in the future","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2016-06-20T20:27:53Z","receivedAt":"2016-06-20T20:35:26Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Norbert Kiesel writes:\n\n> For the record: the faulty commit is\n> https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf\n\nThat commit is part of master. Are you sure you don't have it already?\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"}]}