> it also makes it easier for us to integrate with other Git providers such as GitLab, BitBucket or Phabricator.

I worry sometimes that we've made GitHub too loadbearing so its great to see a devtools company embrace git more generally that just GitHub

Thanks! (author here)

Agreed. In a personal project I'm hoping to release I've taken the approach of integrating at the Git layer, but then providing some small quality of life improvements if you're using Git{Hub,Lab} in a way that I can easily support more in the future. GitHub is not Git.

Huh, I didn't see the .lisp coming in the linked source code.

But since T1892 is presumably their internal ticket tracker, I wonder why this got the call-out

> (not (str:containsp "ssh.dev.azure.com" repo))

; https://github.com/screenshotbot/screenshotbot-oss/blob/main...

Azure DevOps has an additional requirement that Git clients support a protocol feature called "multi-ack". We don't support it yet, and we didn't think we need it.

Rather than blocking our roll-out on implementing multi-ack, we just disabled this for Azure DevOps for now. We do have a fallback as long as the user isn't using shallow clones.

I'm confused. Git does have built-in support for shallow clones:

    git clone --depth=1 $repository

will only fetch the latest versions of files.

You can even use the `--filter=tree:0` option to `git clone` with `git sparse-checkout` to only fetch subsets of the repository.

Yes, but our SaaS tool required our customers to not use sparse or shallow checkouts since we needed the git commit-graph.

Using upload-pack allowed us to remove that constraint, since even in a shallow clone we can still get the commit graph via SSH from the remote.

But your post seemed to indicate you already had access to the commit graph. Is this just about getting that information without depending on APIs?