Menu
▾
▴
gnuplot-beta
|
From: Colin B. <m4...@ya...> - 2020-06-25 07:20:22
|
Hello, Git cloning https://git.code.sf.net/p/gnuplot/.... fails with remote: Compressing objects: 100% (18752/18752), done. error: object f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow: invalid author/committer line - date causes integer overflow fatal: Error in object fatal: index-pack failed Best wishes, Colin Baxter URL: http://www.Colin-Baxter.com --------------------------------------------------------------------- GnuPG fingerprint: 68A8 799C 0230 16E7 BF68 2A27 BBFA 2492 91F5 41C8 --------------------------------------------------------------------- |
|
From: Tait <gnu...@t4...> - 2020-06-25 10:25:06
|
Curious; I don't get that error. What version of git are you using, on what OS? Cloning into 'gnuplot-main'... remote: Enumerating objects: 86573, done. remote: Counting objects: 100% (86573/86573), done. remote: Compressing objects: 100% (18752/18752), done. remote: Total 86573 (delta 70470), reused 83123 (delta 67685) Receiving objects: 100% (86573/86573), 24.98 MiB | 8.77 MiB/s, done. Resolving deltas: 100% (70470/70470), done. But that said, the referenced commit does clearly have an invalid date: tree 31bef65a8811b246449435d6334cd03b80364528 parent 8d0b9267c9f623c99a2f949652180e2e07845847 author Timothee Lecomte <tim...@en...> 7465328412 +0200 committer Timothee Lecomte <tim...@en...> 1154067612 +0200 Reword the warning about problems with piping /dev/null with mouse support... ...to reflect 4.2 behaviour. If I've calculated correctly, 7465328412 would be about July, 2206. In any case, it and others (like 3cc23982) are part of history now, so I can't understand why git doesn't warn by default instead of treating it as fatal. I'm guessing this only affects old versions. There was a config option to turn it down to a warning, which I assume would let you clone successfully: https://github.com/c3e/grundgesetz-dev/issues/28 Colin Baxter <m4...@ya...> said (on 2020/06/25): > Hello, > > Git cloning https://git.code.sf.net/p/gnuplot/.... fails with > > remote: Compressing objects: 100% (18752/18752), done. > error: object f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow: invalid author/committer line - date causes integer overflow > fatal: Error in object > fatal: index-pack failed > > Best wishes, > > > Colin Baxter |
|
From: Colin B. <m4...@ya...> - 2020-06-25 20:07:49
|
>>>>> Tait <gnu...@t4...> writes:
> Curious; I don't get that error. What version of git are you
> using, on what OS?
For some reason, my replies get rejected by
gnu...@li.... This follow-up is therefore my reply.
I'm using git version 2.9.5 on 3.16.0-11-686-pae #1 SMP Debian 3.16.84-1
(2020-06-09) i686 GNU/Linux. I see the latest git is 2.27.0 so perhaps I
should upgrade; however, gnuplot is the first git repository that's
given the error.
Best wishes,
>>>>> Colin Baxter <m4...@ya...> writes:
> Hello,
> Git cloning https://git.code.sf.net/p/gnuplot/.... fails with
> remote: Compressing objects: 100% (18752/18752), done. error:
> object f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow:
> invalid author/committer line - date causes integer overflow
> fatal: Error in object fatal: index-pack failed
> Best wishes,
> Colin Baxter URL: http://www.Colin-Baxter.com
> ---------------------------------------------------------------------
> GnuPG fingerprint: 68A8 799C 0230 16E7 BF68 2A27 BBFA 2492 91F5
> 41C8 ---------------------------------------------------------------------
> _______________________________________________ gnuplot-beta
> mailing list gnu...@li... Membership
> management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
|
|
From: Dima K. <gn...@di...> - 2020-06-25 20:38:17
|
Colin Baxter <m4...@ya...> writes: > For some reason, my replies get rejected by > gnu...@li.... It requires that the From: address is subscribed to the list, which could be tripping you up. I'm having trouble reproducing. Can you please post the exact command that's failing? Thanks. |
|
From: Colin B. <m4...@ya...> - 2020-06-26 06:24:51
|
Hello Dima,
>>>>> Dima Kogan <gn...@di...> writes:
> Hi. Yes, that's probably what's happening. What I meant to ask
> though, was the exact "git clone" command that's failing. What
> repo are you pulling down? I tried some older git builds on i686,
> and they all work fine with the gnuplot repo. Maybe I'm not
> cloning exactly the thing you were cloning?
Sorry about the misunderstanding.
The failing command is
`git clone https://git.code.sf.net/p/gnuplot/gnuplot-main <RET>'
--------- Begin screen output -----
Cloning into 'gnuplot-main'...
remote: Enumerating objects: 86573, done.
Counting objects: 100% (86573/86573), done.
remote: Compressing objects: 100% (18752/18752), done.
error: object f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow: invalid author/committer line - date causes integer overflow
Error in object
fatal: index-pack failed
--------- End screen output --------
Hope this helps.
As a test, I've added by head the Newsgroup name to this email, so if
successful this message will also appear in the news list.
Best wishes,
Colin.
Colin Baxter
URL: http://www.Colin-Baxter.com
|
|
From: Dima K. <gn...@di...> - 2020-06-27 05:09:41
|
Colin Baxter <m4...@ya...> writes: > The failing command is > `git clone https://git.code.sf.net/p/gnuplot/gnuplot-main <RET>' Hmmm. I tried on an older i686 build of Ubuntu (identical to Debian in most ways), and it works ok. Old-ish git too: root@ubuntu-s-1vcpu-1gb-nyc1-01:~# dpkg -l git ... 1:2.7.4-0ubuntu1.6 i386 We COULD fix the repo, but it's not obviously worth the trouble if this isn't even clearly reproducible. Any theories about what specifically is causing the trouble on your box? It's not the i686 or the older git, at least not on their own. |
|
From: Colin B. <m4...@ya...> - 2020-06-27 07:57:48
|
Dear Dima,
>>>>> Dima Kogan <gn...@di...> writes:
> Colin Baxter <m4...@ya...> writes:
>> The failing command is `git clone
>> https://git.code.sf.net/p/gnuplot/gnuplot-main <RET>'
> Hmmm. I tried on an older i686 build of Ubuntu (identical to
> Debian in most ways), and it works ok. Old-ish git too:
> root@ubuntu-s-1vcpu-1gb-nyc1-01:~# dpkg -l git
> ... 1:2.7.4-0ubuntu1.6 i386
> We COULD fix the repo, but it's not obviously worth the trouble if
> this isn't even clearly reproducible. Any theories about what
> specifically is causing the trouble on your box? It's not the i686
> or the older git, at least not on their own.
I've installed the latest git (Version 2.27.0) but I get the same
cloning errors. Time allowing, I'll investigate further.
Thank you very much for your help.
Best wishes,
Colin.
Colin Baxter
URL: http://www.Colin-Baxter.com
|
|
From: Colin B. <m4...@ya...> - 2020-06-27 12:16:18
|
If I comment-out the `fsckObjects = true' setting in my ~/.gitconfig then I can pull the gnuplot repro successfully. Thanks again. Best wishes, Colin. Colin Baxter URL: http://www.Colin-Baxter.com |
|
From: Dima K. <gn...@di...> - 2020-06-27 18:20:53
|
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? |
|
From: Ethan A M. <me...@uw...> - 2020-06-27 18:44:21
|
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 |
|
From: Dima K. <gn...@di...> - 2020-06-27 18:55:46
|
Ethan A Merritt <me...@uw...> writes: >> 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. /I/ never told you anything about it :) Commits are immutable. A fix would be to edit the offending commits to create new commits with a more reasonable date. Then everything in the future from those rewritten commits would be replayed to create a new master branch that doesn't have the tainted history. >From git's point of view this new master branch would be a fork that has branched off at the time of the date fix: in 2006. > What's the recipe for doing so? "git filter-branch" This is relatively straightforward. I can make a fixed master branch, if you'd like to look at it. > 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. You can go back and change whatever you like, but each time you do that, you're making a new fork. In my view it could be justified to fix a failure (like the one that started this thread), but not for anything else. Even in this case, it's not obviously justified: you need an old git and/or i686 AND the failure only shows up if you "git fsck" |
|
From: Ethan A M. <me...@uw...> - 2020-06-27 20:44:21
|
On Saturday, 27 June 2020 11:55:25 PDT Dima Kogan wrote: > Ethan A Merritt <me...@uw...> writes: > > >> 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. > > /I/ never told you anything about it :) > > Commits are immutable. A fix would be to edit the offending commits to > create new commits with a more reasonable date. Then everything in the > future from those rewritten commits would be replayed to create a new > master branch that doesn't have the tainted history. > > From git's point of view this new master branch would be a fork that has > branched off at the time of the date fix: in 2006. What state would that leave the 5.2 and 5.4 stable branches in, that split off after 2006? Do they see the same fix? Does the branch structure even survive? > > What's the recipe for doing so? > > "git filter-branch" Thanks. I will read up on it. > > > > 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. > > You can go back and change whatever you like, but each time you do that, > you're making a new fork. In my view it could be justified to fix a > failure (like the one that started this thread), but not for anything > else. Even in this case, it's not obviously justified: you need an old > git and/or i686 AND the failure only shows up if you "git fsck" Yeah, I don't think this particular glitch warrants a fork. I don't really see why a date typo is any worse than any other typo in the commit message - the structure and sequence of the commit chain is not affected. > This is relatively straightforward. I can make a fixed master branch, if > you'd like to look at it. I'd rather learn about the process and experiment on my own. I'm not sure that looking at the result of someone else's fix teaches me everything needed. thanks, Ethan |
|
From: Dima K. <gn...@di...> - 2020-06-27 22:36:17
|
Ethan A Merritt <me...@uw...> writes: > On Saturday, 27 June 2020 11:55:25 PDT Dima Kogan wrote: > >> From git's point of view this new master branch would be a fork that has >> branched off at the time of the date fix: in 2006. > > What state would that leave the 5.2 and 5.4 stable branches in, > that split off after 2006? Do they see the same fix? > Does the branch structure even survive? Each git commit has a hash (a long hex sequence) that is used to uniquely refer to it. A branch or a tag is just a convenient alias to a specific hash. If we go back to fix the date, then that commit gets a new hash AND ALL DOWNSTREAM COMMITS get a new hash too. I.e. we made a fork. The original hashes that we had before the fix are still there: the filter-branch command creates a new sequence of commits, without deleting the old ones. What we do with that new sequences of commits is up to us. Since branches are aliases to existing hashes, by creating a new sequence of commits with a fixed date we haven't actually changed anything about existing branches or tags. Each branch or tag we want to fix would need to be fixed with filter-branch and then force-pushed to the server (because this wouldn't be the usual append-only push). Probably the best bet would be to leave all the old tags and branches alone, and to only fix the under-development master branch. But that's a choice we make. > Yeah, I don't think this particular glitch warrants a fork. I don't > really see why a date typo is any worse than any other typo in the > commit message - the structure and sequence of the commit chain is not > affected. I think I agree. It doesn't sound like many people are experiencing this failure. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X