I think this problem is avoidable, if we do not delete the other tag.
-----------------
Here's a may-not-too-complex way to add a rel/style tag after a vote passes.
It can be done with two command:
git tag -m "proj-name-1.2.3 rc1 released" rel/proj-name-x.y.z proj-name-x.y.z^{}
git push origin rel/proj-name-x.y.z
How to understand the above commands:
1) git tag: create a tag.
2) -m "message"
make an "annotated tag" that includes this message
3) rel/proj-name-x.y.z that is the name of the "new" tag to create
4) proj-name-x.y.z that is the name of an existing reference tag
5) ^{} this is a git syntax for "peeling the onion" and it means to
change the reference from the annotated tag proj-name-x.y.z to
the commit the tag is annotating.
You can use the git show ...tag-name... on both tags to confirm they point to
the same commit hash.
6) the 2nd command just pushes the new tag that was created to the upstream
repo.
-Marshall
On 10/29/2019 5:36 PM, Richard Eckart de Castilho wrote:
> On 29. Oct 2019, at 22:04, Richard Eckart de Castilho <[email protected]> wrote:
>>> Meanwhile, none of our previous releases that came over from SVN were named
>>> this
>>> way, so they're not protected, but perhaps that's not too important, because
>>> they're in SVN in read-only status.
>> I don't think it would hurt if we renamed these tags.
> Well, there is one issue - but I don't think it is of much practical
> relevance:
>
> During the Maven release process, a "<tag>" element is added to "<scm>"
> section
> of the POM. This points to the tag that is created by Maven during the
> release.
> If we rename the tag after the release, the element points to a non-existing
> tag.
>
> The Hadoop project (per your pointer) doesn't seem to use the Maven release
> plugin
> and their POMs don't seem to include an SCM section.
>
> Do you think it is a problem if the "<tag>" element misses the "rel/" due to
> a tag
> renaming after the release?
>
> Cheers,
>
> -- Richard
