Re: Cloning errors - SOLVED

[Ethan A M. <me...@uw...>]

On Saturday, 27 June 2020 11:20:40 PDT Dima Kogan wrote:
> Colin Baxter <m4...@ya...> writes:
> 
> > If I comment-out the `fsckObjects = true' setting in my ~/.gitconfig
> > then I can pull the gnuplot repro successfully.
> 
> Ah, I can reproduce it now. Thanks for poking at it, Colin. On an older
> i686 box:
> 
>   $ git fsck
> 
>   Checking object directories: 100% (256/256), done.
>   error in commit f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow: invalid author/committer line - date causes integer overflow
>   error in commit 3cc239823f5447fdb739014e076463c8da6225dd: badDateOverflow: invalid author/committer line - date causes integer overflow
>   Checking objects: 100% (86573/86573), done.
> 
> Both of these commits are from 2006, but "git log" says "Date: Thu Jan 1
> 00:00:00 1970 +0000". On a more recent amd64 box I don't get "git fsck"
> to complain, but the commits are still there, and their date is more
> interesting: "Date: Sun Jul 27 02:03:19 2206 +0200".
> 
> It isn't particularly difficult to fix this for the master branch, but
> since this would be a history rewrite, the resulting tree would be a
> fork, effectively. There aren't a ton of people committing to this repo,
> so fixing it wouldn't be too disruptive. Strong feelings either way?

Really?   It's fixable?
I thought you guys all told me it was basically impossible to edit a commit log
entry deep in the tree.  What's the recipe for doing so?  

FWIW there is at least one other date error in the history.  But really there are
many places I'd go back to correct typos if it were possible.   I think git would be
much improved by keeping the commit messages in such a way that they could
be edited later without disruption.

	Ethan