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

Previous Next

Full log

Message #14 received at 53163 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Maxime Devos <maximedevos <at> telenet.be>, 53163 <at> debbugs.gnu.org
Subject: Re: [bug#53163] [PATCH] doc: Document some reasons for/against git
 tags/commits.
Date: Mon, 10 Jan 2022 22:36:14 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.