https://clojurians.slack.com/archives/C015AL9QYH1/p1636403633022600

^^ if you use git deps and like to test things, would be happy for a :thumbsup: if this new CLI prerelease 1.10.3.1029 works as expected

b/c gitlibs repo dir structure has changed, you should see this as if gitlibs cache is stale (so will see downloads of git repos etc)

While testing this and updating some of my projects, I noticed that the short SHA in the README for the test-runner seems to be incorrect:

io.github.cognitect-labs/test-runner 
                              {:git/tag "v0.5.0" :git/sha "b3fd0d2"}

that's the sha of the tag I think, which points to the commit (this is an annotated tag)

yeah

either is ok as they both unpeel to the same commit

% clj -Sdeps '{:deps {io.github.cognitect-labs/test-runner {:git/sha "b3fd0d2" :git/tag "v0.5.0"}}}' -Stree
Cloning: 
Checking out:  at 48c3c67f98362ba1e20526db4eeb6996209c050a
...
io.github.cognitect-labs/test-runner  48c3c67
...

the way the validation works, it checks that both the sha prefix and the tag unpeel to the same full commit sha, which they do

Weird. Looking on the tags page of the repo, it shows this short SHA: {:git/tag "v0.5.0" :git/sha "48c3c67"} which is what I've been using.

and that's not wrong

annotated tags are objects in the git store, just like commits and that tag object itself is b3fd0d2, which points to commit 48c3c67

lightweight tags are NOT objects in the git store and won't have their own sha

they are just name refs that refer to a commit

b/c of how I usually look up the sha, I'm probably usually getting the tag sha, rather than the commit sha, which admittedly might be confusing

usually I do git rev-parse --short v0.5.0

but I can probably do git rev-parse --short v0.5.0^{commit} to get the commit tag instead and then it will match what people see on gh

(the latter is closer to what gitlibs is doing)

Ah, interesting. Thanks.