# unable to pull from remote if commit date is in the future 10 messages from 2016-06-20 to 2016-06-20. Participants: Norbert Kiesel, Stefan Beller, Jeff King, Eric Deplagne, Andreas Schwab. Thread: https://gitlist.dev/t/42670 ## Norbert Kiesel, 2016-06-20 18:41 Subject: unable to pull from remote if commit date is in the future Message-ID: URL: https://gitlist.dev/e/CAM%2Bg_NswH8fd8aFPEHfSLYnZWptNU2GX%3DxTWpehzjTJfJM_GfQ%40mail.gmail.com ``` Hi, I'm following an upstream repo on github. Today morning I saw a new commit there, but a `git pull` in my clone did not fetch it and instead said "Already up-to-date.". On closer inspection, github reports commit time as 2152-06-19. The same project has some other commits with commit time in the future that were fetched. My guess is that happened when those commits got a child with commit date in the past. Is there any way to force git pulling that request? (Perhaps I should try to tell git that it's really 2152?) For the record: the faulty commit is https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf ``` ## Norbert Kiesel, 2016-06-20 19:05 Subject: Re: unable to pull from remote if commit date is in the future Message-ID: URL: https://gitlist.dev/e/CAM%2Bg_NtNAWpLkbErL5-BUyH_3X4rYGfZwO0o-Hfu8zyam8pw7Q%40mail.gmail.com In-Reply-To: ``` Hmm. On closer inspection that commit 23c07cc that github shows with date 2152-06-19 is already in my local branch. I got confused because locally it is shown with a different date: `git log -1 --format='%ci' 23c07cc` shows "2106-02-07 06:28:56 -40643156" which is invalid. My system is running Debian unstable 64bit. Is git using the time rendering methods from the C library (glibc 2.22-12)? On Mon, Jun 20, 2016 at 11:46 AM, Stefan Beller wrote: > On Mon, Jun 20, 2016 at 11:41 AM, Norbert Kiesel wrote: >> Hi, >> >> I'm following an upstream repo on github. Today morning I saw a new >> commit there, but a `git pull` in my clone did not fetch it and >> instead said "Already up-to-date.". On closer inspection, github >> reports commit time as 2152-06-19. The same project has some other >> commits with commit time in the future that were fetched. My guess is >> that happened when those commits got a child with commit date in the >> past. > > git-pull doesn't care about the commit/author date/time at all. > > All it takes into consideration > is the graph structure of the commits on the local and the remote branch, > i.e. Are there any commits on the remote branch that are not part of the local > branch history? > > >> >> Is there any way to force git pulling that request? (Perhaps I should >> try to tell git that it's really 2152?) > > You need to see if that commit is part of the history of the > remote branch you pulled. > >> >> For the record: the faulty commit is >> https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf >> -- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ``` ## Stefan Beller, 2016-06-20 18:46 Subject: Re: unable to pull from remote if commit date is in the future Message-ID: URL: https://gitlist.dev/e/CAGZ79kZL-ZY_0hZx9uA-ObPvMiD%2BEWvJYQa%2BOfCeQe2RLOPECA%40mail.gmail.com In-Reply-To: ``` On Mon, Jun 20, 2016 at 11:41 AM, Norbert Kiesel wrote: > Hi, > > I'm following an upstream repo on github. Today morning I saw a new > commit there, but a `git pull` in my clone did not fetch it and > instead said "Already up-to-date.". On closer inspection, github > reports commit time as 2152-06-19. The same project has some other > commits with commit time in the future that were fetched. My guess is > that happened when those commits got a child with commit date in the > past. git-pull doesn't care about the commit/author date/time at all. All it takes into consideration is the graph structure of the commits on the local and the remote branch, i.e. Are there any commits on the remote branch that are not part of the local branch history? > > Is there any way to force git pulling that request? (Perhaps I should > try to tell git that it's really 2152?) You need to see if that commit is part of the history of the remote branch you pulled. > > For the record: the faulty commit is > https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ``` ## Jeff King, 2016-06-20 19:39 Subject: Re: unable to pull from remote if commit date is in the future Message-ID: <20160620193928.GA3631@sigill.intra.peff.net> URL: https://gitlist.dev/e/20160620193928.GA3631%40sigill.intra.peff.net In-Reply-To: ``` On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote: > Hmm. On closer inspection that commit 23c07cc that github shows with > date 2152-06-19 is already in my local branch. I got confused because > locally it is shown with a different date: `git log -1 --format='%ci' > 23c07cc` shows "2106-02-07 06:28:56 -40643156" which is invalid. > > My system is running Debian unstable 64bit. Is git using the time > rendering methods from the C library (glibc 2.22-12)? No, git's time code is (mostly) internal routines. Can you show us the output of: git cat-file commit 23c07cc | egrep '^author|committer' Note also that some interfaces (like "git log", and GitHub) will show the author date by default, which might be different than the committer date. The "-40643156" timezone definitely looks suspicious, though. I'm curious if it is bad handling in the time code, or if the commit has corrupt ident lines. -Peff ``` ## Norbert Kiesel, 2016-06-20 19:45 Subject: Re: unable to pull from remote if commit date is in the future Message-ID: URL: https://gitlist.dev/e/CAM%2Bg_NsxQrHedp0BNTjMP9H8XfaK7XaYcGdSSkc%3DBW4QigVixw%40mail.gmail.com In-Reply-To: <20160620193928.GA3631@sigill.intra.peff.net> ``` On Mon, Jun 20, 2016 at 12:39 PM, Jeff King wrote: > git cat-file commit 23c07cc | egrep '^author|committer' author Sean D'Epagnier 5758122296 -40643156 committer Sean D'Epagnier 5758122296 -40643156 date --date='@5758122296' returns "Mon Jun 19 15:24:56 PDT 2152" which is what is shown by github. ``` ## Jeff King, 2016-06-20 19:46 Subject: Re: unable to pull from remote if commit date is in the future Message-ID: <20160620194648.GB3631@sigill.intra.peff.net> URL: https://gitlist.dev/e/20160620194648.GB3631%40sigill.intra.peff.net In-Reply-To: <20160620193928.GA3631@sigill.intra.peff.net> ``` On Mon, Jun 20, 2016 at 03:39:28PM -0400, Jeff King wrote: > On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote: > > > Hmm. On closer inspection that commit 23c07cc that github shows with > > date 2152-06-19 is already in my local branch. I got confused because > > locally it is shown with a different date: `git log -1 --format='%ci' > > 23c07cc` shows "2106-02-07 06:28:56 -40643156" which is invalid. > > > > My system is running Debian unstable 64bit. Is git using the time > > rendering methods from the C library (glibc 2.22-12)? > > No, git's time code is (mostly) internal routines. Can you show us the > output of: > > git cat-file commit 23c07cc | egrep '^author|committer' > > Note also that some interfaces (like "git log", and GitHub) will show > the author date by default, which might be different than the committer > date. The "-40643156" timezone definitely looks suspicious, though. I'm > curious if it is bad handling in the time code, or if the commit has > corrupt ident lines. Actually, I just noticed in your earlier message a link to the public GitHub repository. So to answer my own questions: $ git cat-file commit 23c07cc | egrep '^author|committer' author Sean D'Epagnier 5758122296 -40643156 committer Sean D'Epagnier 5758122296 -40643156 Yes, the timezone really is that ridiculous value. No, the author and committer aren't different. According to GNU date, the correct timestamp is actually in 2152. Offhand, I'd guess that the timestamp exceeding 2^32 is getting converted somewhere inside git to a bogus value, and that's how we end up with 2106. -Peff ``` ## Eric Deplagne, 2016-06-20 19:49 Subject: Re: unable to pull from remote if commit date is in the future Message-ID: <20160620194947.GE24553@mail.eric.deplagne.name> URL: https://gitlist.dev/e/20160620194947.GE24553%40mail.eric.deplagne.name In-Reply-To: <20160620193928.GA3631@sigill.intra.peff.net> ``` On Mon, 20 Jun 2016 15:39:28 -0400, Jeff King wrote: > On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote: > > > Hmm. On closer inspection that commit 23c07cc that github shows with > > date 2152-06-19 is already in my local branch. I got confused because > > locally it is shown with a different date: `git log -1 --format='%ci' > > 23c07cc` shows "2106-02-07 06:28:56 -40643156" which is invalid. > > > > My system is running Debian unstable 64bit. Is git using the time > > rendering methods from the C library (glibc 2.22-12)? > > No, git's time code is (mostly) internal routines. Can you show us the > output of: > > git cat-file commit 23c07cc | egrep '^author|committer' > > Note also that some interfaces (like "git log", and GitHub) will show > the author date by default, which might be different than the committer > date. The "-40643156" timezone definitely looks suspicious, though. I'm > curious if it is bad handling in the time code, or if the commit has > corrupt ident lines. > > -Peff 2106 is the year of unsigned 32-bit unix time bug, would there be any relation ? -- Eric Deplagne ``` ## Jeff King, 2016-06-20 20:00 Subject: Re: unable to pull from remote if commit date is in the future Message-ID: <20160620200011.GC3631@sigill.intra.peff.net> URL: https://gitlist.dev/e/20160620200011.GC3631%40sigill.intra.peff.net In-Reply-To: <20160620194648.GB3631@sigill.intra.peff.net> ``` On Mon, Jun 20, 2016 at 03:46:49PM -0400, Jeff King wrote: > So to answer my own questions: > > $ git cat-file commit 23c07cc | egrep '^author|committer' > author Sean D'Epagnier 5758122296 -40643156 > committer Sean D'Epagnier 5758122296 -40643156 > > Yes, the timezone really is that ridiculous value. No, the author and > committer aren't different. According to GNU date, the correct timestamp > is actually in 2152. Offhand, I'd guess that the timestamp exceeding > 2^32 is getting converted somewhere inside git to a bogus value, and > that's how we end up with 2106. Ah, nope. Everything is working as designed. 5758122296 _is_ in 2152, but that's before we apply the author's timezone offset. :) Timezones are supposed to be [+-]HHMM. So the -40643156 timezone is parsed as -406431 hours, 56 minutes. Which is about 46 years. Hence git printing 2106. You _should_ be able to get the right answer by asking git for --date=local, but it doesn't seem to work. Looks like it is because our tm_to_time_t hits this code: if (year < 0 || year > 129) /* algo only works for 1970-2099 */ return -1; and the caller does not actually check the error. The resulting timezone is the screwed-up -40643156, which is perhaps how it got into the commit in the first place. -Peff ``` ## Jeff King, 2016-06-20 20:02 Subject: Re: unable to pull from remote if commit date is in the future Message-ID: <20160620200209.GD3631@sigill.intra.peff.net> URL: https://gitlist.dev/e/20160620200209.GD3631%40sigill.intra.peff.net In-Reply-To: <20160620194947.GE24553@mail.eric.deplagne.name> ``` On Mon, Jun 20, 2016 at 09:49:47PM +0200, Eric Deplagne wrote: > On Mon, 20 Jun 2016 15:39:28 -0400, Jeff King wrote: > > On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote: > > > > > Hmm. On closer inspection that commit 23c07cc that github shows with > > > date 2152-06-19 is already in my local branch. I got confused because > > > locally it is shown with a different date: `git log -1 --format='%ci' > > > 23c07cc` shows "2106-02-07 06:28:56 -40643156" which is invalid. > > > > > > My system is running Debian unstable 64bit. Is git using the time > > > rendering methods from the C library (glibc 2.22-12)? > > > > No, git's time code is (mostly) internal routines. Can you show us the > > output of: > > > > git cat-file commit 23c07cc | egrep '^author|committer' > > > > Note also that some interfaces (like "git log", and GitHub) will show > > the author date by default, which might be different than the committer > > date. The "-40643156" timezone definitely looks suspicious, though. I'm > > curious if it is bad handling in the time code, or if the commit has > > corrupt ident lines. > > > > -Peff > > 2106 is the year of unsigned 32-bit unix time bug, would there be any relation ? In an extremely roundabout way, yes. That -40643156 time zone really is "minus 46 years", but it was generated by _different_ code trying to compute the author timezone on the fly and using a stray "-1". So I suspect that no matter what time you ask for in the year 2152 (or later), the same process would end up with the 2106 time, as the timezone is custom-computed to end up back at the same error point. -Peff ``` ## Andreas Schwab, 2016-06-20 20:27 Subject: Re: unable to pull from remote if commit date is in the future Message-ID: <87porbip12.fsf@linux-m68k.org> URL: https://gitlist.dev/e/87porbip12.fsf%40linux-m68k.org In-Reply-To: ``` Norbert Kiesel writes: > For the record: the faulty commit is > https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf That commit is part of master. Are you sure you don't have it already? Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ```