Closed Ma27 closed 2 months ago
first of all: sorry for the late feedback!
And yea, i know that the current implementation is not perfect but this is, as you say, very bare-bone. If I have the time (or you?) we have to implement it with the improvements you mentioned. Without that I don‘t think its ready to be merged! (Also some tests would be nice here 😄 )
Fixed by #46
Sorry for not getting back to you, but thanks for improving this regardless! :)
The previous version had a few issues I got bitten by:
it's on gitea/gitlab/github not necessary to have
.git
as suffix for a remote, i.e.git@github.com:org/repo
is perfectly fine and because I wasn't that, all of my remotes were dismissed by this plugin.
For forked repos I usually adhere to the convention to name my own fork's remote
origin
while the original repo's origin is calledupstream
[1]. This also means that if an issue is referenced in a file, it refers to the upstream's issue tracker.Accordingly I patched this part to prefer the upstream remote over the origin remote (if it exists).
This is just a very bare-bone setup missing a few more important things:
on github at least you can also specify owner#issuename for issues in forks. This is still completely ignored.
the prefer remote X over Y should be at least configurable, perhaps it should be possible to do this on a per-project level.
For me, the current state is good-enough to use and I figured I'd contribute my changes back here even though the patch is not perfect, perhaps they're useful as a base to improve this nice plugin.
[1] https://docs.github.com/en/get-started/quickstart/fork-a-repo