Open pull requests in browser with extra leading slashes removed

[hrzlgnm]

PR Description

This allows for having extra slashes in git URLs. Especially in submodules. Those may be used to avoid warnings with older bitbake fetcher implementations in yocto. Which warns about relative urls when not having a slash in git urls.

• [email protected]:project/repo.git -> generates a warning in bitbake, which is annoying.
• [email protected]:/project/repo.git -> does not generate a warning in bitbake.

But when trying to open a PR from lazygit with an url like [email protected]:/project/repo.git leads to https://bitbucket.org//project/repo being opened and one has to stare at a blank page unless one removes the extra / manualy.

This PR updates the regex used for matching git url fragments in a way, that the extra / is ignored.

Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[stefanhaller]

I am a little bit reluctant about this change; those don't look like valid URLs to me (I find this hard to tell though, it's difficult to find official documentation about this). Wouldn't it be better to submit bug fixes to whatever software has trouble parsing them? (I don't know what "bitbake fetcher" is...)

On the other hand, there's the "be liberal in what you accept" thing, and stripping the slashes doesn't seem harmful, so why not. I guess I could be persuaded.

[stefanhaller]

Why is the added [^/] needed? The /* before the owner is a greedy match, so it will consume all the leading slashes.

[hrzlgnm]

Good question, i'll check again whether it is needed.

[hrzlgnm]

You were right, those were not needed.

[hrzlgnm]

@stefanhaller I tried the mentioned: regoio.herokuapp.com from line 4 to debug the regex, but that link seems to be dead, do you mind if I also update the url to something working like https://regex101.com/, which also has support for Golang regex?

[stefanhaller]

You were right, those were not needed.

Good. Please squash the second commit into the first; see https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#commit-history.

do you mind if I also update the url to something working like https://regex101.com/,

Yes please, that's a good change (separate commit of course). I use regex101 myself most of the time, it's great.

[hrzlgnm]

@stefanhaller Done as requested, Thanks you for your review.

[hrzlgnm]

I am a little bit reluctant about this change; those don't look like valid URLs to me (I find this hard to tell though, it's difficult to find official documentation about this). Wouldn't it be better to submit bug fixes to whatever software has trouble parsing them?
(I don't know what "bitbake fetcher" is...)

I totally agree on that, but the release one sometimes has to work with may not be maintained anymore so a bug report is pointless, the issue is most likely already fixed in newer versions.

[hrzlgnm]

Just for the reference, bitbake from yocto-3.0.0 produces the mentioned warning here:
https://github.com/openembedded/bitbake/blob/5d83d828cacb58ccb7c464e799c85fd2d2a50ccc/lib/bb/fetch2/gitsm.py#L111
Which can be worked around with adding an extra /

The issue is probably still presetn as the warning is still present on the master branch:
https://github.com/openembedded/bitbake/blob/90da82bd2bfcfd5590c9ae06015737b616074b56/lib/bb/fetch2/gitsm.py#L111

[stefanhaller]

Excellent, thanks!