[bug#53163] [PATCH] doc: Document some reasons for/against git tags/commits.

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Montag, dem 10.01.2022 um 22:08 +0100 schrieb Maxime Devos:
> A v2 patch with the suggestions applied is attached.
LGTM, but let's wait for more opinions.  Since this does concern Guix
as a whole I don't want to be the sole dictator here.

> 
> >   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.
> 
> Here "tags" = releases on content.minetest.net, and not Git tags?
Yep, "tags" = contentdb releases, I forgot the terminology here :)
> > 

> > That's a general question that has not reached a conclusion yet. 
> > IIRC the goal was to make tags more robust by replacing them with
> > git-describe like tags.  This would also make it easier to port
> > between revisioned commit and tagged one, since one would have to
> > let-bind commit either way.
> 
> FWIW, the git updater in (guix upstream) might need to be modified to
> support the "git describe" style in commit fields, and a linter
> to verify that the tag+number corresponds to the commit (to
> avoid some ‘tricking peer review’ issues), but otherwise this
> seems rather nice to me.  I didn't investigate closely though.
Yeah, in my opinion we'd also want a (git-tag VERSION COMMIT) procedure
to produce it, which is definitely c-u material.  And obviously long
hashes would be required.

Cheers