radian-software
.gitconfig rewrites and forge proxies break straight.el
What's wrong
https://github.com/hlissner/doom-emacs/issues/2679
Any changes to the url, whether due to .gitconfig rewrites or forge proxies require manual intervention to rewrite the URL. This is something that should probably be handled transparently.
Directions to reproduce
Add harmless .gitconfig referenced in the URL above, then start Emacs with at least one straight-managed package that has not yet been installed/updated.
Version information
- Emacs version: 27.2
- Operating system: Linux
What benefit does straight.el extract from tracking redirects? I'm genuinely asking since I might be missing something.
Since the redirects are "lower in the stack" than straight.el, it seems to me that proxy.github.company.io can basically be treated as github.com in that environment, so there should be no need to alter the default mapping. Vim-plug (an admittedly much simpler piece of software) does things this way for example.
I'll have to look into this more deeply when I have time, but the issue probably lies in either straight-vc-git--urls-compatible-p
or straight-vc-git--ensure-remote.
In the latter, we determine the remote's URL by running:
git config --get remote.REMOTE.url
I believe running:
git ls-remote --get-url REMOTE
Instead would factor in any rewrite rules in your git config. Not sure if that is the appropriate change or not.
@raxod502 Thoughts?
@progfolio You hit the nail on the head. The issue is that your suggested fix does not address proxies.
My question still stands though - What benefit do we extract from performing this check? I'm sure there is one, I just don't know what it is.
What benefit do we extract from performing this check?
If by "this check" you mean straight-vc-git--urls-compatible-p, the idea is that when you've updated the Git URL for a package in its recipe, you want straight.el to be able to tell, and update it in the repository git-remote. However, for this to work, we need a way to check whether the current remote URL in the repository matches the one the recipe specifies.
Not sure if that is the appropriate change or not. @raxod502 Thoughts?
Yeah, that looks right to me.
it seems to me that proxy.github.company.io can basically be treated as github.com in that environment
If I understand correctly, in your environment you're using Git remote URLs that have proxy.github.company.io embedded literally in them, and the issue is that straight.el wants to change them to use github.com instead. Is that right?
I think what you actually want is to use a rewrite rule in your Git configuration, like
% git config --global url."https://proxy.github.company.io".insteadOf "https://github.com"
which would make all of this work transparently. Otherwise, it seems to me like you'll run into issues where MELPA recipes will refer to github.com when you actually want them to refer to proxy.github.company.io.
Not sure if that is the appropriate change or not. @raxod502 Thoughts?
Wait, no. I've read through again more thoroughly and I think I misunderstood what was happening here. When doing the recipe normalization we have 2 options for which URL to look at for a remote:
- the URL configured directly in Git's config
- the URL as amended after any rewrite rules are applied
I'm pretty sure we want to always use (1) rather than (2). And I suspect that there is some place where we're accidentally using (2) when creating a remote or reading its value, for example, instead of (1). Having a rewrite rule in place shouldn't affect any of the values that straight.el reads or writes in Git configuration.
@wurosh:
I think what you actually want is to use a rewrite rule in your Git configuration, like
% git config --global url."https://proxy.github.company.io".insteadOf "https://github.com"
which would make all of this work transparently. Otherwise, it seems to me like you'll run into issues where MELPA recipes will refer to github.com when you actually want them to refer to proxy.github.company.io.
Does this address the issue for you?
@wurosh:
I think what you actually want is to use a rewrite rule in your Git configuration, like
% git config --global url."https://proxy.github.company.io".insteadOf "https://github.com"which would make all of this work transparently. Otherwise, it seems to me like you'll run into issues where MELPA recipes will refer to github.com when you actually want them to refer to proxy.github.company.io.
Does this address the issue for you?
Unfortunately no. I already had that in my .gitconfig (as an attempt at fixing this). If the .gitconfig issue is resolved however, the proxy issue becomes irrelevant. Let me try out the changes suggested above and report back.