fix(browse): reject commits missing from remote

[vjymisal0]

Summary

git-browse can construct a repository URL for a local commit that the selected remote does not contain. Such links fail when opened. Check the remote-tracking refs before constructing the URL and report a clear error when the commit has not been pushed.

Changes

• Verify HEAD is contained by a ref under the selected remote.
• Add a regression test for a local-only commit.
• Seed the existing browse tests with a remote-tracking ref.

Test plan

• bash -n bin/git-browse
• git diff --check
• Manual published/unpublished commit reproduction

Fixes #1153

[spacewander]

The commit hash is only embedded in the URL when a filename is given, but the new check runs on every invocation — so git browse with no filename (whose URL never contains the commit) gets blocked unnecessarily.

[vjymisal0]

Thanks for catching this @spacewander! I’ve limited the remote-commit validation to invocations that include a filename, so still opens the repository even when HEAD is unpushed. I also added a regression test for that case. Verified with bash syntax checks and manual pushed/unpushed filename scenarios; the local environment doesn’t have Bats installed.

[vjymisal0]

Thanks for the CI report. The new regression test was still invoking the no-filename form while expecting rejection. I updated it to pass ./browse_this, which preserves the intended rejection for file URLs while the separate no-filename test verifies repository browsing with an unpushed HEAD. Pushed as f7b5ec5.

[spacewander]

Why add the filename guard?

[vjymisal0]

When no filename is provided (e.g. git browse or git browse ), the command opens the repository root URL (e.g. https://github.com/owner/repo), which does not include any commit hash and always succeeds even with unpushed local commits.

When a filename is specified, the URL embeds $commit_or_branch (e.g. .../blob//), which returns a 404 on GitHub/GitLab if the commit has not been pushed to that remote. The filename guard allows general repo browsing to work freely while protecting file permalinks against 404s.

[vjymisal0]

Thanks for catching this @spacewander! I updated the remote-commit check to run only when a filename is provided, so continues to open the repository URL even with an unpushed local commit. I also added a regression test and tightened the remote matching. Verified with bash syntax checking and manual pushed/unpushed cases; the full Bats suite could not run here because is not installed.

[vjymisal0]

Thanks @spacewander — the remote commit check is now limited to URL forms that include a filename, while remote-only browsing remains unaffected. Added regression coverage for remote branch matching and unpushed file commits; the branch is clean and pushed.

[hyperupcall]

I'm not convinced this is necessary. If the commit doesn't exist on remote, the web page will open, and it will 404. This gives information to the user, who can then push and refresh the page.

With this new code, the user will have to run this command again in that case. Additionally, the user will be shown a non-standard error, and if the network is slow, then this command will take even longer to complete.

[vjymisal0]

Thanks for the thoughtful feedback @hyperupcall! That makes complete sense — avoiding the additional network round-trip keeps git-browse snappy, and landing on the remote 404 page naturally prompts the user to push if needed without requiring a re-invocation.

[hyperupcall]

Great glad that we agree