"git bug push" fails with "Error: repository not found" when using custom SSH configuration

Labels: resolution/duplicate

Timeline

dev-lab (dev-lab) opened

When i attempt to execute git bug push, it fails with the following error:

Error: repository not found

I am working with a remote git server accessible via ssh, and I define the connection configuration in .ssh/config like this (data is mangled):

Host privategit
    Hostname 8.8.8.8
    Port 4242
    IdentityFile ~/.ssh/dev@lab
    User git

My git origin looks like this:

$ git remote get-url origin
privategit:my-project

I suspect this issue is related to #944, which dealt with ignoring insteadOf configurations. However, in my case, the issue appears to be related to git-bug ignoring SSH configurations defined in ~/.ssh/config. The standard Git CLI works fine with the configuration, but git-bug seems unable to use it.

sudoforge commented

what version of gopass are you using?

any failure here would be due to go-git, unfortunately. HEAD is quite different than the last release (0.8.0) -- but 0.8.1 should be cut by the end of the month, and part of that includes an update of dependencies, which may or may not solve this problem.

dev-lab (dev-lab) commented

I don’t have gopass installed, and I'm using SSH with key-based authentication.

It looks like this issue stems from limitations in go-git, which git-bug relies on. Specifically, go-git has long-standing issues with not respecting ~/.ssh/config. For example, this one from their old repo: src-d/go-git#1220. There are also similar unresolved issues in the newer go-git/go-git repo — but most of them have gone stale.

Given that there's little hope go-git will support parsing ~/.ssh/config anytime soon, would it be possible for git-bug to offer an option to use the system git binary for remote interactions (e.g., as a build-time option or fallback)?

That would solve this kind of issue without waiting on upstream go-git changes.

sudoforge commented (edited)

I don’t have gopass installed

🤦 i totally meant git-bug. my fingers hit g, and some part of my brain told them to autocomplete the completely wrong program. my bad!

It looks like this issue stems from limitations in go-git, which git-bug relies on

yeah, go-git/go-git is sort of the canonical implementation of git in golang.

Given that there's little hope go-git will support parsing ~/.ssh/config anytime soon, would it be possible for git-bug to offer an option to use the system git binary for remote interactions (e.g., as a build-time option or fallback)?

That would solve this kind of issue without waiting on upstream go-git changes.

resolving issues like this will be a focus for me after the 0.8.1 (maintenance) release. there isn't a current plan for how to tackle this, but i think forking out to git may be a reasonable approach, but there are a few alternatives that will be considered. i personally use ssh heavily, and this will need to get solved :)


in the meantime, you should be able to accomplish this by changing your git configuration. the following two commands should change the remote URI and the command git uses to execute ssh in a way that emulates the configuration you provided:

$ git remote set-url origin git@8.8.8.8:my-project

$ git config --local core.sshcommand "ssh -i ~/.ssh/dev@lab -p 4242"

upon further testing, go-git doesn't appear to support core.sshcommand either. le sigh.... i also tested with the latest release of go-git, and it still fails these use cases.


upon even more testing and research, it appears that the way go-git is written expects you (or git-bug in this case) to detect and customize the transport layer and options from git configuration manually. because of the variance in how users set up their git (and in this case, ssh) configuration, this can get unweildy. i'll explore this route more in the future, but simply forking out to git on the host system would be a simple way to do this without reinventing the wheel.

dev-lab (dev-lab) commented

Thanks for testing it and confirming the limitation with core.sshCommand. I really appreciate you not brushing off the issue — looking forward to seeing how this evolves after 0.8.1.

sudoforge added label kind/bug

sudoforge added label priority/important-longterm

sudoforge added label triage/accepted

sudoforge added label area/git

sudoforge added label root-cause/go-git

sudoforge removed label root-cause/go-git

sudoforge commented

please track #940 for further updates.

sudoforge closed the bug

sudoforge removed label kind/bug

sudoforge removed label priority/important-longterm

sudoforge removed label triage/accepted

sudoforge removed label area/git

sudoforge added label resolution/duplicate