Re: ELPA git repo contains zero-padded file modes and running ~$ make fails

[Stefan Monnier]

Hola Omar,

Omar Antolín Camarena [2024-02-01 17:52:15] wrote:
>> For example you will create commit
>> 2b2e62af001312a9b97724855855dfec51b5bec6 on Oct 13, 2065.

Oh, wow, even better!
The 1970 timestamp is kinda boring, but 2065 seems downright creative.
I wonder how it got there!

> Correct. I have no idea how that happened either! And I don't know how to
> keep from happening again. Maybe I'm more prone to the issue because
> I commit from WSL on Windows and from a VM or Chroot on ChromeOS: I usually
> have the "outer" Windows or ChromeOS clock visible, but I usually have no
> idea what time the "inner" Linux environment thinks it is.

No idea how WSL works, sorry, but for ChromeOS, if it's a chroot or
container then it should use the exact same clock as the host, AFAIK.

> But still: 1970, 2065?  How did that happen and why does it only happen
> occasionally?  But prevention of further instances is not as important
> as fixing the current problem:

Actually, fixing the old ones is not that useful if new ones will appear
shortly again.  So it might be worth trying to see if you can reproduce
the problem somehow.

You might want to open a bug report with Git, actually: whatever wrong
time you machine may have, Git shouldn't generate a commit with date
which it will later label as "badDateOverflow".
[ I assume here that you created those commits with the "official" Git
  client.  AFAIK there are several (re)implementations of (part of) Git out
  there, of varying quality.  ]

> Stefan Monnier mentioned rebasing but I'm unclear on what I am supposed to
> rebase on what (and I'm also unclear on how that would help: wouldn't the
> weird commit still be present?). I'll gladly do whatever is necessary to fix
> the embark repository now, I just don't understand what exactly Stefan
> proposes I do.

By rebasing I mean reconstruct an almost identical history, except that
the offending commits are reconstructed with a "better" date.
This normally result in a whole new set of commits IDs (even though the
commits look eerily like the old ones).  It's quite nasty because any
other branches out there will "lose" their connection/relationship to
your branch (because they don't know those new commits and how those
new commits relate to the old ones), so merges and updates get all
screwed up.

It's not urgent (since apparently Git doesn't always complain about it),
but if nobody else beats me to it, I'll try and create such a "fixed"
history when I find the time.


        Stefan