Hello,
Am 31.10.22 um 08:45 schrieb Slawomir Jaranowski:
We are talking about a situation which happens very rarely - canceling a
vote.
In such a case simply delete tag and create next with next release run with
the same label is easy and possible.
If your GIT repository has fetched some tag from the remote, it will NOT
update this tag later on automatically nowadays. Some clients fetch the
tags every 15 minutes, so you will probably have got the wrong tag already.
After that you will have the wrong version tags in some local repository
after the tag was modified on remote.
From the "git help fetch"
| Since Git version 2.20, fetching to update refs/tags/* works the same
| way as when pushing. I.e. any updates will be rejected without + in
| the refspec (or --force).
(2.20 was released on 2018-12-09)
What is the workflow, if one tries to reproduce some issue on a special
version? Do you really download the ZIP afresh for each such occasions
or do you create a branch in your local repository from that specific
version tag and start from there?
I understand the reason *against* burning is the question:
"why there is a GIT tag but not a release".
The reason *for* burning is the question:
"why the GIT tag is different to the release."
For me, the former is way easier to spot and explain, the latter is
error-prone on the user's side if the user is not aware that the tags
are to be ignored or explicitely fetched before switching versions.
Additionally, the latter may happen for other version artifact as well.
MFG
--
Heiko Studt
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
