Support authenticated HTTP

[jaraco]

Today I set out to use jj to author a change in a Github project. I cloned the repo following the example in the tutorial, which uses https. After authoring some changes, I sought to push the changes in a branch, but I encountered the error:

 distutils $ jj git push --branch remove-msvc
Branch changes to push to origin:
  Add branch remove-msvc to df9a5c634ac1
Error: Unexpected git error when pushing: remote authentication required but no callback set; class=Http (34); code=Auth (-16)

Searching around for how to set up auth, it appears that jj currently only supports SSH for authenticated connections.

As a former Windows user, I still retain some of my habits from that time, where SSH workflows were clumsy at best, and in my git environments, I rely solely on HTTP workflows. As I explore migrating from git to jj, I'd like to minimize the variance across the workflows.

I'd like to see jj add support for authenticated HTTP, ideally by also re-using the credentials already stored in the backing store used by the auth helpers found in the git client. I may be able to help here.

Is there any prior work to support this mode? Are there any known blockers?

[martinvonz]

The credentials callback is configured here. As you can see, there's only support for SSH right now. I'd be very grateful for help in this area. I don't know how these things should work, so I'm afraid I don't have many hints. There's e.g. gitcredentials that we may want to integrate with somehow. I also don't know how if any of this should be done in libgit2. I found one old issue that mentions gitcredentials.

[martinvonz]

FYI, Git's credentials helpers came up in #63 too.

[ilyagr]

As a workaround, I use jj init --git-repo=.. I then use git pull/ git push inside the repository. It works surprisingly well, and also allows seeing diffs highlighted in editors as a bonus. However, expect occasional problems from races between jj and git, especially if you use something like VS Code does a git fetch at random intervals. These problems often take the form of "divergent" commits, and can usually be recovered from using jj abandon.

A safer option is to use a separate git dir, as described in the doc I linked.

I couldn't get git push to work with the git repo jj creates inside .jj when you do a normal jj git clone, though.

[ShaddyDC]

It would be nice to also support GIT_ASKPASS or SSH_ASKPASS to allow using eg KWallet.

I guess there are workarounds like this, but it would be nice if repositories that worked with git would work with jj ootb.

[neongreen]

Hit this issue today -- would be great if jj could at least say "only ssh is supported for now". For me the error only happens with jj git push but not with jj git fetch -- so I thought something was wrong with my git config.

[jeanbza]

Yeah, I'm also running into this. Our organisation has a private GitHub, which only allows https (why? I have no idea :|), making jj unusable. Nothing valuable to add to this conversation except throwing out another example use case.

[neongreen]

FWIW i was actually wrong and jj does work with HTTP-only remotes (we have a gitlab instance with disabled ssh). But I don't know how I got it to work. Maybe just a token in ~/.git-credentials? Idk

[ShaddyDC]

Same for me, I'm not on my work machine so I can't check, but I think it was something including the credentials manager to cache credentials in the session. I have to use a git command once, like git fetch, to get the credentials from kwallet, and afterwards, jj can access them just fine.

[jaraco]

I have to use a git command once, like git fetch, to get the credentials from kwallet, and afterwards, jj can access them just fine.

Oh! That explains a lot. When I started investigating this issue, I was looking into the code and I could see that it was handling authenticated HTTP with a credential manager, but yet I couldn't push. I never got around to tracing the cause, but if the current implementation is relying on the credentials being cached, then maybe all that remains is to provide a hook to resolve the credentials when they're not cached.