deps.edn support for :git/branch + :git/sha

Question

Are there plans to add a :git/branch key for Git libs in deps.edn that works like :git/tag? In other words, Git refs (:git/branch or :git/tag) have to be paired with a Git SHA (:git/sha) to lock to a specific commit as Git refs can be updated to point to different commits.

For example:

{:deps {owner/repo {:git/url "https://github.com/owner/repo.git"
                    :git/branch "1.x"
                    :git/sha "2fd4e1c67a2d28fced849ee1bb76e7391b93eb12"}}}

The purpose is to support projects using major version branch workflows as compared to tag + release workflows.

Major version branch workflows may be used for things like private polyrepo projects (e.g. a web service where the API specs/model, backend, and infrastructure-as-code templates are split) that don't need the additional overhead that comes with using tags + releases.

Auto-update tools like Renovate or Dependabot can use the Git ref key in a deps.edn Git lib to update its locked :git/sha.

For tag + release workflows, this may be some heuristic like semantic versioning.

For major version branch workflows, the auto-update tool needs to use something like :git/branch to:

1. Tie break between a given Git SHA's descendants if there's multiple.
2. Ignore PR branches on the tip of a given branch (e.g. ignore a PR branch that's a descendant of the tip of the main branch).

Answer 1

As we discussed in Slack, the intent here is to pinpoint a specific commit which is done via :git/sha with long sha. The current support for :git/tag allows you to provide a short sha and use the :git/tag as an extra check on the commit (so long sha not necessary) while also providing a human readable "version".

Because branches are virtual refs, change over time, and are easier to delete and recreate, they are not a suitable for verification of single short sha, and that's why we don't support them now.

If you are providing long shas, you don't need :git/tag or a branch verifier at all - you could provide one now and it would just be ignored. If you wanted to use an external process to trigger an external sha update process, you could, all of that is compatible with existing deps.edn.

I'm not sure about the nuances of what you are proposing re auto update. I guess there are distinct aspects encoded currently:

1. what "versions" are considered (current answer: tagged)
2. how to order those versions (current answer: most descendant sha = "newer")

It sounds like you are proposing a new strategy for #1 that would involve "commits on a branch but not on some kinds of sub branches". I'm not sure how to make that generically viable but happy to hear ideas. #2 seems same as currently used.

Comments

From further discussions in the Clojurians Slack: Git deps as they exist today are more intended for publishing libs and tools, not for supporting organizations with large dependency graphs of private Git repos where you really want to track a main branch and not tags (e.g. service model spec repo → backend repo → infrastructure repo update propagation).

A workaround today would be to make all repositories have some shared structure under an imaginary "parent folder" and then use something like Git subtrees, Git submodules, or something else to assemble them all into a build directory. That way, all `deps.edn` files can use `:local/root "../other-dep"` to reference things.