Fix tag fetch conflicts that break detect-version

[DenKoren]

Run milaboratory/github-ci/actions/detect-version@v1
with:
canonize: true
fetch-depth: 100
/usr/bin/git fetch --deepen=1 origin refs/tags/:refs/tags/
From https://github.com/milaboratory/redberry-pipe

• [new tag] 1.0.0 -> 1.0.0
  ! [rejected] 1.1.0 -> 1.1.0 (would clobber existing tag)
• [new tag] v0.9 -> v0.9
• [new tag] v0.9.1 -> v0.9.1
• [new tag] v0.9.2 -> v0.9.2
• [new tag] v0.9.3 -> v0.9.3
• [new tag] v0.9.4 -> v0.9.4
• [new tag] v0.9.5 -> v0.9.5
• [new tag] v0.9.6 -> v0.9.6
• [new tag] v0.9.7 -> v0.9.7
  Error: command "git 'fetch' '--deepen=1' 'origin' 'refs/tags/:refs/tags/'" failed with code '1':

From https://github.com/milaboratory/redberry-pipe

[DenKoren]

Reproduced:

mkdir redberry-pipe && cd redberry-pipe
git init
git remote add origin '[email protected]:milaboratory/redberry-pipe.git'
git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin '+9c20ee1d8206c8088041e4d26bd76597d31ee890:refs/tags/1.1.0'
git checkout --progress --force refs/tags/1.1.0
git fetch --deepen=1 origin 'refs/tags/*:refs/tags/*'

[DenKoren]

Here it the magic:

action/checkout@v2 does the command, that puts specific commit into local tag.
Here is the data stored in tag after checking out the repository 'like action does':

[20:27:13] ~/w/m/t/redberry-pipe  ((1.1.0)|✔)
denkoren@DenKorenmbp [1]> cat .git/refs/tags/1.1.0
9c20ee1d8206c8088041e4d26bd76597d31ee890

If we ask git to show the contents of object 9c20ee1d8206c8088041e4d26bd76597d31ee890 we'll see the commit itself:

[20:27:16] ~/w/m/t/redberry-pipe  ((1.1.0)|✔)
denkoren@DenKorenmbp > git cat-file -p 9c20ee1d8206c8088041e4d26bd76597d31ee890
tree 25a3f5eaa163d0ac416191455d1c968434afefd7
parent cdc7ac8db9c66d1dee3e040b9d9da4c3b3e7215f
author Dmitriy Bolotin <[email protected]> 1644956829 +0300
committer Dmitriy Bolotin <[email protected]> 1644957229 +0300

feat: allow normal build without miRepo credentials

Now, when we ask git to fetch remote tags, we face the conflict:

[20:28:56] ~/w/m/t/redberry-pipe  ((1.1.0)|✔)
denkoren@DenKorenmbp [1]> git fetch -vvv --deepen=1 origin 'refs/tags/1.1.0:refs/tags/1.1.0'
want efe26941740c0f9ccab05b3ac23575795dece507 (refs/tags/1.1.0)
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 1), reused 2 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 328 bytes | 109.00 KiB/s, done.
From github.com:milaboratory/redberry-pipe
 ! [rejected]        1.1.0      -> 1.1.0  (would clobber existing tag)

The first log line tells us the same tag in remote repository points to another object. How can it be?

Git has 2 types of tags: regular and annotated. The difference is that regular tag points directly to specific commit, while annotated tag contains annotation (message) bound to tag, stored in separate object, which then points to target commit:

[20:29:16] ~/w/m/t/redberry-pipe  ((1.1.0)|✔)
denkoren@DenKorenmbp [1]> git cat-file -p efe26941740c0f9ccab05b3ac23575795dece507
object 9c20ee1d8206c8088041e4d26bd76597d31ee890
type commit
tag 1.1.0
tagger Dmitriy Bolotin <[email protected]> 1645094961 +0300

This is what really happens:

• remote repository contains annotated tag, that points to object with annotation and pointer to commit
• GitHub's 'checkout' action fetches specific commit into local tag. This causes creation of 'regular' local tag, that points directly to commit object
• when we fetch remote tags, git gets tag 1.1.0 with annotation object. This object's hash differs from commit's hash.
• TA-DA! Conflict! :)