[Bug]: Https-remotes without the suffix .git sync fine, but commands open file on GH/open file history on GH break. Adding the suffix results in valid URLs.

[Gewerd-Strauss]

Describe the bug

Assume a repository has the following HTTPS-remote:

• origin:https://github.com/user-redacted/BE31-Thesis-quarto

The plugin can easily push to and pull from this remote. This remote is also completely valid for use in commandline git, or my git-client Fork.

However, the commands Open file on GitHub and Open file history on GitHub error out with the error-message noted below if the remote is configured as described above.

If I change the origin-remote to https://github.com/user-redacted/BE31-Thesis-quarto.git (i.e. I add the .git-suffix), these commands suddenly do work properly, and the plugin prints nothing to the console.

Relevant errors (if available) from notifications or console (CTRL+SHIFT+I)

plugin:obsidian-git:34716 Uncaught (in promise) TypeError: object null is not iterable (cannot read property Symbol(Symbol.iterator))
    at getData (plugin:obsidian-git:34716:62)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async openHistoryInGitHub (plugin:obsidian-git:34681:16)

Steps to reproduce

1. Set up a vault backed with a github-remote via HTTPS, by using the syntax https://github.com/%user_name%/%repo_name%
2. Add a note to it, commit & push it to the remote.
3. Attempt to open its history, and notice it failing.
4. Modify the remote to point at https://github.com/%user_name%/%repo_name%.git.
5. Repeat step 3. The respective history for this file on GH should now be opened in your browser.**

Expected Behavior

As an HTTPS-remote seems to be valid with and without the .git-suffix for fetch/push/pull operations - at least as far as I can determine on my end - the presence or absence of said .git-suffix should not break this command.

Addition context

My vaults are set up to sync via HTTPS, but an intermediary step using SSH is done via pageant and respective SSH-keys. As a consequence, the backend of the interface uses SSH and the respective setup.

As a consequence, I currently can't test if this is an artifact of using pageant to handle multiple users on the same remote:
I have obsidian-vaults on GH under this user Gewerd-Strauss, and under another-user. All my git repos are set up with https-remotes in the format of git@user-redated-repos:user-redated/BE31-Thesis-quarto, using pageant.
Pageant handles the SSH-key for user-redacted-repos and user-redacted-gists and manages the communication thereafter.

Additionally,

• executing Edit remotes in obsidian yields git@user-redacted-repos:user-redacted/BE31-Thesis-quarto.git*.
• executing git origin -v via the CLI returns origin git@user-redacted-repos:user-redacted/BE31-Thesis-quarto.git (fetch) & origin git@user-redacted-repos:user-redacted/BE31-Thesis-quarto.git (push)*

However, as the other instructions of the git-plugin work successfully (e.g. commit, push, pull) I don't think this to be the result of using SSH via pageant.

---

*For both of these, the suffix .git can be missing if the remote is set up as https://github.com/user-redacted/BE31-Thesis-quarto instead. In this case, everything works except for Open File ...-commands.

**The exception here are notes in submodules, for whom the URL will be constructed based on the main repository's URL, resulting in an invalid URL being executed. See #592. For these files, it obviously does not matter if the remote ends in .git or not.

Operating system

Windows

Installation Method

None

Plugin version

2.24.3