checkout overwrites tags with lightweight tags

[Adam-]

When running checkout with fetch-depth: 0 on a tag ref, checkout clobbers the fetched tag by replacing it with its own lightweight tag.

The cause of this is testRef is comparing a tag-object with a commit-object. git rev-parse on a non-lightweight tag ref returns the tag object and not the commit object:

  // refs/tags/
  else if (upperRef.startsWith('REFS/TAGS/')) {
    const tagName = ref.substring('refs/tags/'.length)
    return (
      (await git.tagExists(tagName)) && commit === (await git.revParse(ref))
    )
  }

After this test fails, checkout then performs a 2nd fetch of the commit which results in a lightweight tag being created, overwriting the original tag.

This breaks git describe and other things.

Build log:

$ git cat-file -t 64c28bc66b5420d8bfb158088b830fc6cdb02815
tag
$ git cat-file -p 64c28bc66b5420d8bfb158088b830fc6cdb02815
object 4583104281ae74cb64a04aa28615c062752f1d64
type commit
tag R2
tagger James Carroll <eloquism@gmail.com> 1659879755 +0100

Test

$ git cat-file -t 4583104281ae74cb64a04aa28615c062752f1d64
commit
$ git cat-file -p 4583104281ae74cb64a04aa28615c062752f1d64
tree 0f020f42f0099856c28e138234f6cb22130bde36
parent 483c83b4723c31e32a6722985f16a840742c99b3
author James Carroll <eloquism@gmail.com> 1659879639 +0100
committer James Carroll <eloquism@gmail.com> 1659879727 +0100

Test fetch without force

 /usr/bin/git -c protocol.version=2 fetch --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/*
...
   * [new branch]      main       -> origin/main
   * [new tag]         R1         -> R1
   * [new tag]         R2         -> R2
  /usr/bin/git tag --list R2
  R2
  /usr/bin/git rev-parse refs/tags/R2
  64c28bc66b5420d8bfb158088b830fc6cdb02815
  /usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules origin +4583104281ae74cb64a04aa28615c062752f1d64:refs/tags/R2
  From https://github.com/MrCarroll/runelite-snap
   t [tag update]      4583104281ae74cb64a04aa28615c062752f1d64 -> R2

[ihostage]

It's really very unexpected behaviour 🤔
Moreover, this issue initiates other problem with using some tools that depends on type of tags (JGitVer for example).

And for cutting a release I must use workaround and re-fetch all tags manually 😞

- name: Checkout
  uses: actions/checkout@v3
  with:
    # we don't know what commit the last tag was
    fetch-depth: 0
- run: git fetch --tags --force origin # WA: https://github.com/actions/checkout/issues/882

[Simonl9l]

not sure if anyone is monitoring this...any and all help appreciated!

I added the work around but if I do a repo.Tags.CountI() I still get zero!

the is what I see in the log:

Run git fetch --tags --force origin
  git fetch --tags --force origin
  shell: /usr/bin/bash -e {0}

I note when the workflow is retrieve the repo it runs:

 /usr/bin/git -c protocol.version=2 fetch --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/*

It seem I'm running checkout@2 as that is what Nuke.build is currently using.

[chrisd8088]

We've run into this as well when upgrading our workflows for the Git LFS project. Our proposed workaround at present is to run the following:

    - uses: actions/checkout@v3
      with:
        fetch-depth: 0
    - run: git fetch origin "+${GITHUB_REF}:${GITHUB_REF}"
      if: ${{ github.ref_type == 'tag' }}
      shell: bash

That seems to be enough to reverse the tag update made by mistake which overwrites the annotated tag and turns it into a lightweight one.

[rinnnn]

For me the annotated tag appears as lightweight even when I checkout without the fetch-depth: 0 restriction. Workarounds suggested above work fine.

[DJViking]

A full workday wasted to investigate why Jgitver did not work in GitHub Actions.
Then I found this issue. The problem was filed here over a year ago. Why has it not yet been fixed?

Thankfully a workaround exist.
I am currently using this in my workflow

    run: git fetch --depth=1 origin +refs/tags/*:refs/tags/*

But this is a hack, and it clutters the workflow.

[walles]

Related to #290, possibly a duplicate?