unable to pull from remote if commit date is in the future

> 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.

>
> 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

> On Mon, Jun 20, 2016 at 11:41 AM, Norbert Kiesel <nkiesel@gmail.com> 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

> 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 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.

> So to answer my own questions:
> 
>   $ git cat-file commit 23c07cc | egrep '^author|committer'
>   author Sean D'Epagnier <seandepagnier@gmail.com> 5758122296 -40643156
>   committer Sean D'Epagnier <seandepagnier@gmail.com> 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.

> 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

> 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 ?