From: Maxime Devos <maximedevos@telenet.be>
To: 53163@debbugs.gnu.org
Subject: [bug#53163] [PATCH] doc: Document some reasons for/against git tags/commits.
Date: Thu, 30 Jun 2022 11:35:44 +0200 [thread overview]
Message-ID: <e4132f76e27642f16006d57a40711e3bd2a473c6.camel@telenet.be> (raw)
In-Reply-To: <5623ec2b15bf60a51587b0592ad178b2bec3ef37.camel@telenet.be>
[-- Attachment #1: Type: text/plain, Size: 2574 bytes --]
> I think we should separate reference material from guidelines.
> Perhaps this should rather go under “Packaging Guidelines”, next to
> “Version Numbers”?
I suppose for consistency with the ‘Packaging Guidelines’ chapter, I
could move it there, though I'd like to add a cross-reference to the
description of ‘commit’ in git-reference for convenience, e.g. maybe:
‘commit’
This string denotes either the commit to fetch (a hexadecimal
string), or the tag to fetch. You can also use a “short”
commit ID or a ‘git describe’ style identifier such as
‘v1.0.1-10-g58d7909c97’. **To decide between choosing a
commit or a tag, the guidelines in [cross-reference] may be
useful.**
?
(At first I'd have preferred to not separate reference material to keep
all information on commits together, but on second thought separating
them would be more orderly and it's not like we don't have cross-
references, so maybe it would be better to split ...)
> Toggle quote (4 lines)
> > +Commits make reviewing somewhat trickier, because the reviewer has
> > +to
> > +verify that that the commit actually corresponds to the package
> > version.
> I'd also add a line regarding the difficulty to verify that a commit
> did once belong to a tag as a future reader, but I'm not sure what
> exactly to advise here and how. In the particular case of minetest,
> we have an external map of "tags" to commits that can be queried, but
> for most repos I fear the tags would simply be lost to time.
FWIW, the same holds (though maybe to a lesser degree in practice?) for
hashes and tarballs), not specific to git.
Anyway, SWH keeps this historical information, e.g. here are two lists
of tags->commits of the Minetest repo at two different points in time:
* https://archive.softwareheritage.org/browse/snapshot/d063751724753b97de41a34aa3d1779186530bb4/releases/?origin_url=https://github.com/minetest/minetest×tamp=2020-01-18T00:07:33Z
* https://archive.softwareheritage.org/browse/snapshot/81e0233dbaf285922bef2281f4e5cbbe5fbc7ea0/releases/?origin_url=https://github.com/minetest/minetest×tamp=2022-06-25T04:01:20Z
That assumes trusting SWH to be correct of course (and a bit of a
SPOF though I don't expect problems), but with some work, things can
be verified even for repos that delete tags.
Anyway, any remaining comments or a second opinion? (Would like more
than three people for something like this?)
Greetings,
Maxime.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
prev parent reply other threads:[~2022-06-30 9:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-10 15:27 [bug#53163] [PATCH] doc: Document some reasons for/against git tags/commits Maxime Devos
2022-01-10 19:43 ` Liliana Marie Prikler
2022-01-10 21:08 ` Maxime Devos
2022-01-10 21:36 ` Liliana Marie Prikler
2022-01-26 11:40 ` Ludovic Courtès
2022-06-30 9:35 ` Maxime Devos [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e4132f76e27642f16006d57a40711e3bd2a473c6.camel@telenet.be \
--to=maximedevos@telenet.be \
--cc=53163@debbugs.gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.