From: "Ludovic Courtès" <ludo@gnu.org>
To: Timothy Sample <samplet@ngyro.com>
Cc: guix-devel@gnu.org, Liliana Marie Prikler <liliana.prikler@gmail.com>
Subject: Re: On raw strings in <origin> commit field
Date: Mon, 03 Jan 2022 16:46:16 +0100 [thread overview]
Message-ID: <87sfu4hlfb.fsf@gnu.org> (raw)
In-Reply-To: <874k6nqrhs.fsf@ngyro.com> (Timothy Sample's message of "Sat, 01 Jan 2022 12:45:51 -0500")
Hello!
Timothy Sample <samplet@ngyro.com> skribis:
> If you want a concrete example to think through, there’s ‘eclib’. Our
> package says it’s version “20190909”, but that’s not what upstream calls
> version “20190909”. It looks like when we packaged ‘eclib’, that tag
> pointed to commit 19e7e3e74268bf78bd9a1c4ba07597d5434fb166, but now it
> points to bfbbd7c414521e1bf5e718a2925ea8ad845a2e87.
[...]
> First, as expected, finding the original commit was painful. SWH did
> not record the old version of the tag.
It probably did: SWH archives the “history of histories”. However, our
SWH code, ‘lookup-origin-revision’, is looking at the tag found in the
latest snapshot, which is not helpful in this case.
[...]
> Second, these cases are very, very rare. (I’ve essentially checked
> every Git origin since Guix version 1.0.0, and this problem is not one
> that worries me). “Tricking Peer Review”-style problems seem to be much
> more prevalent. When tracking down a “difficult” Git origin, the first
> thing I do is grep the Guix Git history for a “oops I committed the
> wrong hash” message. I recommend we focus our energies there before
> worrying too much about replacing tags with commits or using both or
> whatever.
Agreed, it’d be nice to address, but not concern #1.
> And as a bonus, if you want to be really kind to future time travellers,
> when fixing an errant hash, please include a nice hint as to what the
> original hash was for (like a commit hash). We have commit
> ca5a791f6285b08506ccd662d5911ccf0c4d1ece in our repo, which says:
>
>> The previous hash was from the "dev" branch of the repository.
>
> I can’t find the source for the previous hash, and if I could actually
> travel through time, I would change the commit message to:
>
>> The previous hash was from commit abcd0123..., which comes from the
>> "dev" branch of the repository.
In commit 944bd79113b9c856b11dd2b40d40e0274a9f4dd9 I added an
explanation right in the source; I think that’s a transparent and clear
way of handling issues with tags modified in place.
Ludo’.
next prev parent reply other threads:[~2022-01-03 15:46 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-28 20:55 On raw strings in <origin> commit field Liliana Marie Prikler
2021-12-29 8:39 ` zimoun
2021-12-29 20:25 ` Liliana Marie Prikler
2021-12-30 12:43 ` zimoun
2021-12-31 0:02 ` Liliana Marie Prikler
2021-12-31 1:23 ` zimoun
2021-12-31 3:27 ` Liliana Marie Prikler
2021-12-31 9:31 ` Ricardo Wurmus
2021-12-31 11:07 ` Liliana Marie Prikler
2021-12-31 12:31 ` Ricardo Wurmus
2021-12-31 13:18 ` Liliana Marie Prikler
2021-12-31 13:15 ` zimoun
2021-12-31 15:19 ` Liliana Marie Prikler
2021-12-31 17:21 ` zimoun
2021-12-31 20:52 ` Liliana Marie Prikler
2021-12-31 23:36 ` Mark H Weaver
2022-01-01 1:33 ` Liliana Marie Prikler
2022-01-01 5:00 ` Mark H Weaver
2022-01-01 10:33 ` Liliana Marie Prikler
2022-01-01 20:37 ` Mark H Weaver
2022-01-01 22:55 ` Liliana Marie Prikler
2022-01-02 22:57 ` Mark H Weaver
2022-01-03 21:25 ` Liliana Marie Prikler
2022-01-03 23:14 ` Mark H Weaver
2022-01-04 19:55 ` Liliana Marie Prikler
2022-01-04 23:42 ` Mark H Weaver
2022-01-05 9:28 ` Mark H Weaver
2022-01-05 20:43 ` Liliana Marie Prikler
2022-01-06 10:38 ` Mark H Weaver
2022-01-06 11:25 ` Liliana Marie Prikler
2022-01-02 19:30 ` zimoun
2022-01-02 21:35 ` Liliana Marie Prikler
2022-01-03 9:22 ` zimoun
2022-01-03 18:13 ` Liliana Marie Prikler
2022-01-03 19:07 ` zimoun
2022-01-03 20:19 ` Liliana Marie Prikler
2022-01-03 23:00 ` zimoun
2022-01-04 5:23 ` Liliana Marie Prikler
2022-01-04 8:51 ` zimoun
2022-01-04 13:15 ` zimoun
2022-01-04 19:45 ` Liliana Marie Prikler
2022-01-04 19:53 ` zimoun
2021-12-31 23:56 ` Mark H Weaver
2022-01-01 0:15 ` Liliana Marie Prikler
2021-12-30 1:13 ` Mark H Weaver
2021-12-30 12:56 ` zimoun
2021-12-31 3:15 ` Liliana Marie Prikler
2021-12-31 7:57 ` Taylan Kammer
2021-12-31 10:55 ` Liliana Marie Prikler
2022-01-01 1:41 ` Mark H Weaver
2022-01-01 11:12 ` Liliana Marie Prikler
2022-01-01 17:45 ` Timothy Sample
2022-01-01 19:52 ` Liliana Marie Prikler
2022-01-02 23:00 ` Timothy Sample
2022-01-03 15:46 ` Ludovic Courtès [this message]
2022-01-01 20:19 ` Mark H Weaver
2022-01-01 23:20 ` Liliana Marie Prikler
2022-01-02 12:25 ` Mark H Weaver
2022-01-02 14:09 ` Liliana Marie Prikler
2022-01-02 2:07 ` Bengt Richter
2021-12-31 17:56 ` Vagrant Cascadian
2022-01-03 15:51 ` Ludovic Courtès
2022-01-03 16:29 ` Vagrant Cascadian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sfu4hlfb.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=liliana.prikler@gmail.com \
--cc=samplet@ngyro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).