Fork me on GitHub
Alex Miller (Clojure team)20:11:15

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

Alex Miller (Clojure team)20:11:57

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)


I can confirm that it re-downloads my git deps.


Just out of interest, do the gitlibs changes change how checked out git coord directories are exposed up via a lib-map (e.g. returned from Background is that some of my code is pulling out the :deps/root key from the lib-map for each dependency, then scanning that directory using standard file I/O. So if that directory itself is still just a vanilla checkout of the git repo my code will be fine (even if it’s now stored within a different parent hierarchy).


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:

                              {:git/tag "v0.5.0" :git/sha "b3fd0d2"}

Alex Miller (Clojure team)20:11:17

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

Alex Miller (Clojure team)20:11:12

either is ok as they both unpeel to the same commit

Alex Miller (Clojure team)21:11:21

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

Alex Miller (Clojure team)21:11:50

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.

Alex Miller (Clojure team)21:11:45

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

Alex Miller (Clojure team)21:11:12

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

Alex Miller (Clojure team)21:11:32

they are just name refs that refer to a commit

Alex Miller (Clojure team)21:11:02

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

Alex Miller (Clojure team)21:11:10

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

Alex Miller (Clojure team)21:11:42

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

💯 1
Alex Miller (Clojure team)21:11:13

(the latter is closer to what gitlibs is doing)


Ah, interesting. Thanks.