Repository navigation
Request support git "insteadOf" url aliases #1150
Description
Activity
- changed the title
[-]psr should support git "insteadOf" url aliases[/-][+]Request support git "insteadOf" url aliases[/+]on Jan 22, 2025 I don't appreciate the rude tone as I do this on my own time for $0.
Look, I wasn't trying to be rude. I was just opening an issue. I'm sorry to bother you; I'll work on fixing it myself and submit a PR at some point.
I've re-read the original post, and I'm not sure what you've identified as "rude". Was it this?
psr fell over because it couldn't parse a valid remote specification.
Maybe the description is a bit terse, but I think it accurately captures the behavior. I apologize if it came across as rude. For what it's worth, I also work on software for $0 in my spare time, so we have in common, at least.
If other folks want to tackle this, note that the underlying problem is that PSR relies on GitPython, which has been in "maintenance mode" for at least eight years. The most relevant issue was opened backed in 2017, and has remained untouched since then.
The correct path forward is probably to fix this in GitPython, but note that even if it gets fixed there, PSR will need to update its dependencies, which currently pins GitPython to
~= 3.0, whereas GitPython has moved on to 3.1.xx.- added a commit that references this issue
on Jan 22, 2025 It turns out there's a relatively simple way to work around this; I've submitted a pull request that addresses the problem.
Reacted by codejedi365I've re-read the original post, and I'm not sure what you've identified as "rude". Was it this?
psr fell over because it couldn't parse a valid remote specification.
Maybe the description is a bit terse, but I think it accurately captures the behavior. I apologize if it came across as rude.
Thanks for the apology, I was probably having a bit of a long day and took it overly personal as I had never heard of the instead of aliasing option before. It's quite difficult to get all scenarios of use covered.
For what it's worth, I also work on software for $0 in my spare time, so we have in common, at least.
We do, which software is that?
If other folks want to tackle this, note that the underlying problem is that PSR relies on GitPython, which has been in "maintenance mode" for at least eight years. The most relevant issue was opened backed in 2017, and has remained untouched since then.
The correct path forward is probably to fix this in GitPython, but note that even if it gets fixed there, PSR will need to update its dependencies, which currently pins GitPython to
~= 3.0, whereas GitPython has moved on to 3.1.xx.That is good research you have completed and it would be nice to have GitPython still maintained.
No need to bump the version, the approximation value only locks the major version of
3.1 remaining item
- added a commit that references this issue
on Jan 23, 2025 - added 8 commits that reference this issue
on Jan 25, 2025 - added a commit that references this issue
on Jan 26, 2025 🎉 This issue has been resolved in Version 9.17.0 🎉
You can find more information about this release on the GitHub Releases page.
Bug Report
Description
With a configuration like this in my global git config:
I can clone a repository like this:
Which ends up looking like this:
Which ultimately causes psr to fail like this:
Expected behavior
PSR would not have thrown an error because it would have been able to interpret my git configuration and extracted the remote URL just as git normally can.
If you use
git remote get-url <remote>command, it will return a fully expanded url via theinsteadOfsetting.Actual behavior
PSR errored out with a failure message of a bad remote URL because it retrieved the remote url setting which in raw form is an invalid URL rather than using the git interpreter which supports the
insteadOfalias attribute and would of returned a valid remote URL value.Environment