Yes, the problem still exists.

Any update on the git v2 protocol implementation?

Hello,

The kpack team is seeing this problem with our users as well when they try to integrate with Azure DevOps. Just surfacing in case it helps with feature prioritization.

The error in the build logs is this:

Loading secrets for "https://dev.azure.com" from secret "azure-devops-git"
unable to fetch git repository: unexpected client error: unexpected requesting "https://dev.azure.com/*******/" status code: 400

So I have been doing some research into this during the last two weekends, and thought I could share what I have found.

TLDR; The reason we are seeing error messages has less to do with git v2 protocol and more to do with Azure DevOps requiring clients to support multi-ack. Nothing new really going by this issue in the "old" repo.

I followed the suggestions in the issue and attempted to just get "dumb" multi-ack working, which I seem to have achieved with worryingly small amounts of code changes. Most components were there, I just needed to take the changes made in @bashims PR to get external refs working. Here is my fork that currently works with Azure DevOps.
https://github.com/phillebaba/go-git

I have created an example project if you want to try this out yourself. The notification-controller repo has been imported from fluxcd/notification-controller to have way to test identical repos in GitHub and Azure DevOps. You obviously need to set up your own repos as git over ssh requires authenticated users.
https://github.com/phillebaba/go-git-demo

go run main.go --url https://dev.azure.com/philiplaine0831/TEST/_git/notification-controller --destination /tmp/http-azdo-noti
ls /tmp/http-azdo-noti
go run main.go --url git@ssh.dev.azure.com:v3/philiplaine0831/TEST/notification-controller --ssh-key-path ~/.ssh/id_rsa --destination /tmp/azdo-noti
ls /tmp/azdo-noti
go run main.go --url git@github.com:phillebaba/notification-controller.git --ssh-key-path ~/.ssh/id_rsa --destination /tmp/gh-noti
ls /tmp/gh-noti

There is one detail left however, SSH technically works but not without a small cheat.
https://github.com/phillebaba/go-git/blob/3fa0eaceaaf7d66ff559278afc3090e8d6eb14cd/plumbing/transport/internal/common/common.go#L361
Without commenting out this line of code you get an error when closing the connection in the end. The error only appears when cloning larger repositories, and only on Azure DevOps. My guess is that the server is closing the connection before the client can, but I am not too sure. It doesn't help that debugging ssh connections is a pain.

close tcp 10.134.10.7:45060->40.74.28.11:22: use of closed network connection

I would appreciate if anyone could verify the work I have done, as I am pretty new to how the git protocols work. My hope is that we could make an initial PR with the "dumb" multi-ack to get go-git working with Azure DevOps. Then we could attempt implementing proper multi-ack logic which is a bit more complicated.

@phillebaba it looks like my PR is blocked on the test coverage check. I will need to get some pack files to test against.

@bashims are the tests something that you are actively working on, or do you need help getting that done?

@phillebaba, yes I should have them wrapped up by tomorrow.

Hi guys ;) any update on this issue? I've stumbled upon that problem too :/ - blocks me from using go-git on Azure DevOps.

Seems to be a blocker to different projects. I've experienced this issue with flux-cli tool. Any updates on this topic?

@ondrejkolin this has been for the most part solved in Flux as we have moved to support libgit2 as an alternative. I am doubtful we will get support in go-git unless someone decides its worth to spend the time. I had a stab at it 6 months ago and came up with a partial solution which would not be accepted in go-git. It would take someone to fully implement multi-ack capabilities into go-git which isn't the easiest thing to do.

Just FYI https://github.com/google/gitprotocolio has done most of the hard work of parsing git protocol v2.

https://github.com/google/goblet provide a sample usage of that library.

@mcuadros I think that should simplify matters by quite a bit.

Is there an update on getting multi-ack?

@bluebrown one of the limitations of the approach is that the repository can only do a single handshake with the remote. The optimisation I suggested using ListContext, assumes the list operation is taking place on a completely new repository. You then use the result to compare the commit ID with the commit ID from your existing repository.

To help us keep things tidy and focus on the active tasks, we've introduced a stale bot to spot issues/PRs that haven't had any activity in a while.

This particular issue hasn't had any updates or activity in the past 90 days, so it's been labeled as 'stale'. If it remains inactive for the next 30 days, it'll be automatically closed.

We understand everyone's busy, but if this issue is still important to you, please feel free to add a comment or make an update to keep it active.

Thanks for your understanding and cooperation!

Does this issue still exist? Or it does support Azure Repositories now?
If not ,can anyone suggest alternative for it

It is supported for Azure Repos today

It is supported for Azure Repos today

Thank you for the update!

It is supported for Azure Repos today

Huh, since which version? Why isn't it closed then?

Clone of Azure DevOps repositories is supported with the caveats defined in #613 (comment) since version v5.5.0. A working example is available within _examples/azure_devops.

Closing this to avoid future confusion. For additional support please open a new issue.

@anubhav06 for future reference, public repositories work fine as well:

go run _examples/azure_devops/main.go https://dev.azure.com/public-git/sample/_git/sample /tmp/sample "" ""

Hey all,

RedPanda Console is on 5.13 (https://github.com/redpanda-data/console/blob/d6119efd7582ad457ab1fc2ccbec84cf4385dd42/backend/go.mod#L23)

And I'm seeing the same error as described in the initial post

.../git-upload-pack" status code: 400"}

I've verified the PAT used for access is good, and I'm not seeing problems in our istio egress

Is there another way to troubleshoot this?