From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: ELPA git repo contains zero-padded file modes and running ~$ make fails Date: Thu, 01 Feb 2024 22:09:53 -0500 Message-ID: References: <87zha1esp6.fsf@gnu.org> <87blmbs4wg.fsf@ericabrahamsen.net> <87imgcxgar.fsf@bzg.fr> <87msskqitp.fsf@vagabond.tim-landscheidt.de> <87il37df3x.fsf@matem.unam.mx> <87zfwj94i2.fsf@daniel-mendler.de> <87eddvd9ow.fsf@matem.unam.mx> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1770"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Daniel Mendler , Bastien , Eric Abrahamsen , emacs-devel@gnu.org, Tim Landscheidt To: Omar =?windows-1252?Q?Antol=EDn?= Camarena Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 02 04:10:50 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rVjx3-0000Fg-5t for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Feb 2024 04:10:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rVjwN-00026W-Bn; Thu, 01 Feb 2024 22:10:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rVjwL-00026M-PD for emacs-devel@gnu.org; Thu, 01 Feb 2024 22:10:05 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rVjwE-0002Ag-WD; Thu, 01 Feb 2024 22:10:05 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 53EB7442B2F; Thu, 1 Feb 2024 22:09:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1706843394; bh=/yxZNuuAYEotjhRFNa1qviXbgZDtEIQAJ1LoWqmTTQQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LloOwcOgccOD037UGno/Ph+Cq4r3aZ4bxY5tk0T2S0Mtu+w3QRcZVVZLCyvWSVR2N R+COzBMrCxjjxVwlToqW+KUotuuNr3kN7i0gZlhpdXEE/HOaBXZSnp11tu2AZlGGdl rzVadFolxSjaktc/DypgA/UCccqB7MCii+If1av06oePzY8xEj7Uuj2wURoM8KNXaF W3LDl6cHl/wv5uV3d/ExtUe48zE1Ldb/xDWbB7+BCBbJ3xZwPqnZ0nEgxSGsIbH7ya pCSfEFtXSWFjopQgoVp7JFEXfWuphkHIEbbbvHwzzDZA72W3vMo8ngr3BC/WJ/GsRn hgd55mfmX1O7Q== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9BCAA441774; Thu, 1 Feb 2024 22:09:54 -0500 (EST) Original-Received: from pastel (69-165-153-17.dsl.teksavvy.com [69.165.153.17]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 64F6C120BBF; Thu, 1 Feb 2024 22:09:54 -0500 (EST) In-Reply-To: <87eddvd9ow.fsf@matem.unam.mx> ("Omar =?windows-1252?Q?Antol?= =?windows-1252?Q?=EDn?= Camarena"'s message of "Thu, 01 Feb 2024 17:52:15 -0600") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315728 Archived-At: Hola Omar, Omar Antol=EDn 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 usual= ly > 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