> 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
danpalmer 2 days ago [-]
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.
tdrhq 2 days ago [-]
Thanks! (author here)
2 days ago [-]
mdaniel 2 days ago [-]
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
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.
jmholla 2 days ago [-]
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.
tdrhq 2 days ago [-]
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.
jmholla 2 days ago [-]
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?
Rendered at 05:52:51 GMT+0000 (Coordinated Universal Time) with Vercel.
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
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...
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.
You can even use the `--filter=tree:0` option to `git clone` with `git sparse-checkout` to only fetch subsets of the repository.
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.