Bruno Meneguele

@rverma-nikiai can you confirm that the tool mentioned by @zaquestion satisfies your needs? Project management adds another level of complexity to the tool, so it would be better to keep...

Considering the way `lab` works today, I'm kinda skeptical it's still a problem for us. @zaquestion any thoughts? I'm inclined to close it.

+1 for using go-git (do you mean https://github.com/go-git/go-git, right?)! I'm not sure how better/faster it would be, but for sure it seems more suitable than calling git cli directly.

Oh, ok, that's interesting. This seems indeed the "officially supported" module for libgit2. However I think the goal of using go-git is to eliminate the need for any system executable/library...

The only reason for not enabling it by default, from my perspective, is to not break the current behavior. But as you well said, I also don't think most users...

I'm not really familiar with `https_proxy` behavior and never really tested it with `lab`. It doesn't change the remote URL at all, right? Could you retry but using http.proxy git-config...

Hmm, yeah.. it would help only for normal `git` commands, like `lab clone` which is a wrapper for `git clone`. I'm going to investigate it. However, unfortunately, I don't have...

At the same time, it should be already supported, since the env vars are being considered: https://github.com/zaquestion/lab/blob/2e20fc0459551f63edb3d104289e2d433216a057/internal/gitlab/gitlab.go#L86-L103 ``` ProxyFromEnvironment returns the URL of the proxy to use for a given...

@counterbeing tyvm for the bisect info! It's indeed really helpful. Could you both test the latest version but using the additional config option: ``` [tls] skip_verify = true ``` ?

Ok, after some time I came back to look at this issue. I've set a SOCKS tunnel with a server I have access and tried to use lab through it....