Gilt does not recognize tags added after the cache was cloned

[0xDEC0DE]

Spotted when trying to vendor in a fresh change; reproduction is a bit weird:

Steps to reproduce

Setup

mkdir repo cache target
cd repo
git init .
touch monkey
git add monkey
git commit -m 'i has a repo'
git tag -am v1 v1
cd ..
cat << EOF > target/Giltfile.yaml
giltDir: $(pwd)/cache
debug: true
repositories:
  - git: file:https://$(pwd)/repo
    version: v1
    sources:
    - src: monkey
      dstFile: monkey
EOF

Verify setup

cd target
gilt overlay

Finish setup

cd ../repo
touch banana
git add banana
git commit -m 'my hands are typing words'
git tag -am v2 v2
cd ..
cat << EOF > target/Giltfile.yaml
giltDir: $(pwd)/cache
debug: true
repositories:
  - git: file:https://$(pwd)/repo
    version: v2
    sources:
    - src: monkey
      dstFile: monkey
    - src: banana
      dstFile: banana
EOF

Test

cd target
gilt overlay

Expected result

target directory contains monkey and banana

Actual behavior

DBG result output="fatal: invalid reference: v2\n"
[...]
ERR error overlaying repositories err="exit status 128"

Workaround

cd ../cache/cache/*
git fetch --tags

...will update the cache with current data, and the overlay will succeed.

[0xDEC0DE]

Update

• Popping the cache also (obviously) works around the issue
• Using a SHA instead of a tag appears to be unaffected; git worktree will fetch the required objects from the remote if a SHA is used for the version:

[retr0h]

Ahh good catch, py-gilt had the update functionality to facilitate branch support. Let me know if you want me to turn around and release a bug fix release sooner than later.

[0xDEC0DE]

It's easy enough to work around, and our typical use case is in CI pipelines, which pop cache as part of cleanup; we're in no hurry.