[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 15:27 +0000 schrieb Maxime Devos:
> For <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53144#53>,
> I'd like to be able to reference some section (not specialised
> for Minetest packages, instead more general) explaining when
> and when not to use git tags/commits.
Generally LGTM.

> +not tag releases at all, in this case commits are unavoidable.  In a
> +very few cases (@pxref{Version Numbers}), Guix intentionally uses a
"In a very few cases" looks like a typo.  "In few cases" or "In some
exceptional cases" would work well.

> +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.

> I'm not familiar with "git describe", so the documentation
> doesn't tell when to use "git describe"-style
> tag-number of commits-commit strings.
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.

Cheers