FR: use a custom ssh-agent

[quad]

There are many issues related to the use of ssh agents. (see #5228). Personally, I use secretive to store an SSH key in my Github SSH key in my laptop's secure element. However, because jj uses libgit2, it isn't able to support an SSH agent whose identity socket isn't available via $SSH_AUTH_SOCK.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

I'm trying to get libgit2/libgit2#7034 merged in libgit2 upstream. If and when it merges, it would be great if jj offered a config to specify a custom ssh agent identity socket.

Of course, when #5228 is released, I'll be able to fallback to using a git subprocess and .ssh/config override. But building this functionality straight into jj would be more straightforward.

[emilazy]

Of course, when #5228 is released, I'll be able to fallback to using a git subprocess and .ssh/config override. But building this functionality straight into jj would be more straightforward.

FWIW, I don’t think the subprocessing is considered a fallback from libgit2 but instead a replacement. libgit2 fetches and pushes are slow and have a lot of issues even besides the key management problems, and the library causes some pain for packagers. So from discussions on the Discord my understanding is that the plan is to make subprocessing the default and then remove the libgit2 dependency entirely after a while, if it all goes well.

[quad]

@emilazy Oh! Then should I close this issue?

[PhilipMetzger]

So from discussions on the Discord my understanding is that the plan is to make subprocessing the default and then remove the libgit2 dependency entirely after a while, if it all goes well.

Yes, that is also is the plan as I understood it. It may be that we will also have the same support without libgit2 with either Git's native library or Gix, but the libgit2 removal should not impact these.

[emilazy]

Oh! Then should I close this issue?

That’s not really for me to say :) My bias is against libgit2 both as a downstream packager and a user who has had a bunch of problems with it, so I personally consider that code path to be feature‐frozen and just waiting for the Git subprocess support to prove itself robust enough to kill it off. But I don’t call the shots and others may have a more nuanced view than this. After all, libgit2 will still be the default for at least the next release.

[arxanas]

I agree that we're attempting to replace libgit2 SSH rather than fall back. I'll executively close this issue under the presumption that it's resolved in #5228. @quad reopen or file a new issue if you get the newer version of jj (at some point) and it turns out that there's a problem, or it otherwise doesn't resolve your workflow here.

[martinvonz]

But I don’t call the shots and others may have a more nuanced view than this.

IMO, you should all feel authorized to help triage. Others can always reopen if they think you made a mistake.