Repro

Run:

git brws .

Expected results

It opens https://github.com/{owner}/{repo}/tree/{hash}

Actual results

It opened https://github.com/{owner}/{repo}/blob/{hash}

Additional info

URLs for subdirectories (e.g. git brws ./src) are redirected from /blob/ URL to /tree/ URL automatically. However, only a root directory (e.g. git brws .) does not redirect the URL hence 404 error caused on a browser. I think git-brws should not rely on the redirect.

Precondition

• Original: foo/bar
• Forked: rhysd/bar

Repro

git clone https://github.com/rhysd/bar.git
cd bar
g cob patch-1
g push -u origin patch-1
git brws --pr

Expected Behavior

Open https://github.com/foo/bar/compare/master...rhysd:patch-1

Actual Behavior

Open https://github.com/foo/bar/compare/master...patch-1

Repro

cd /outside/git/repo
git brws -r rhysd/git-brws

Expected

Open https://github.com/rhysd/git-brws

Actual

Got an error

Error: Git command ["git", "rev-parse", "--absolute-git-dir"] exited with non-zero status: fatal: Not a git repository (or any of the parent directories): .git

Blocked by seanmonstar/reqwest#1060.

I'm working on this at tokio-0.3 branch.

git-brws version

v0.11.11

Repro

Run:

git clone https://github.com/rhysd/git-brws.git
cd git-brws
git brws -c ./src/main.rs

Expected behavior

Open https://github.com/rhysd/git-brws/blob/master/src/main.rs

Actual behavior

Opened https://github.com/rhysd/git-brws/blob/{hash}/src/main.rs ignoring -c option

Repro

cd /path/to/git-brws
git brws 0.10.0

Expected

The commit page of the tag is opened

Actual

404 page

0b412dc

It appears that Bitbucket does support diff between two commits /tags/branches using the following URL format –

https://bitbucket.org/<owner>/<repoName>.git/branches/compare/<commitHash1>..<commitHash2>#diff

The short option -h does work fine and print the help text:

$ git brws -h
Usage: git brws [Options] {Args}

[...]

    -h, --help          Print this help
    -v, --version       Show version

According to the above help, the long version of the option (--help) is also valid and will show the same help text. However, this doesn't seem working in such a way.

$ git brws --help
No manual entry for git-brws

Followings are some environmental information:

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.6
BuildVersion:	17G4015

$ git --version
git version 2.20.1
hub version 2.7.0

$ git brws --version
0.8.1

I have a Gitlab remote URL with this format:

[email protected]:group/subgroup/repository.git

When trying, for example, to open a commit with the following command:

git-brws aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d

The following URL is opened:

https://example.com/group/subgroup/commit/aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d

It seems like Gitlab subgroups aren't supported.

I'm not a Rust developer so I can't submit a reliable PR within reasonable time, however I've searched a bit and the issue comes from the slug_from_path function:

Instead of considering the URL will be splitted in only two parts, you should use the last element of the iterator as the repository, and join all the other elements with / as the separator.

Job: https://ci.appveyor.com/project/rhysd/git-brws/branch/master/job/2rm5eqvclqhw653f

This failure is only on CI (both Appveyor and GitHub Actions). It is not reproducible on my local Windows machine. All tests passed on my local machine.

.canonicalize() uses \\?... path (extended path length) but it seems not supported by --git-dir. On Windows, --git-dir is not a file path actually. It is a kind of slash-path:

> git rev-parse --absolute-git-dir
D:/a/git-brws/git-brws/.git

\\?\D:\a\git-brws\git-brws\.git for --git-dir seems not available on some version of Windows. Following error occurs at running rev-parse --abbrev-ref --symbolic @{u} command:

fatal: not a git repository: '\\?\C:\git-brws\.git'

Actually it was OK on my local Windows machine to use the \\?... path as far as I tried manually.

Repro

git brws src/../src/argv.rs -u

Expected

https://github.com/rhysd/git-brws/blob/88703f439412d08373e8026b5121a9ed4f30fb88/src/argv.rs

Actual

https://github.com/rhysd/git-brws/blob/88703f439412d08373e8026b5121a9ed4f30fb88/src/../src/argv.rs

Repro

git clone https://github.com/rhysd/wain.git
cd wain/spec-test
git brws ./wasm-testsuite/f32.wast

Expected

Open https://github.com/WebAssembly/testsuite/blob/xxx/globals.wast

Actual

Opened https://github.com/rhysd/wain/blob/xxx/spec-test/wasm-testsuite/f32.wast

Description

git-brws does not consider submodule. When opening file, running git command within the file's directory would solve this.

Repro:

$ cd /path/to/some/repo
$ git brws -d /path/to/another/repo

• Expected: Open repository page for /path/to/another/repo
• Actual: Opened repository page for /path/to/some/repo

Edit: Ignore this, just found the --url option!

Would be neat if there was an option or environment variable that we could use to configure the length of commits in URLs, i.e. when linking things to other people it's neater to link short links rather than long links.

Example

export GIT_BRWS_GIT_COMMIT_LENGTH=8

Would result in:

https://github.com/rhysd/git-brws/blob/6c250cc5/Cargo.toml

Rather than:

https://github.com/rhysd/git-brws/blob/6c250cc53e39666f415f28fd49d3b224e47a2309/Cargo.toml

Is the build of git-brws broken with latest stable?

~/src/git-brws$ git log --oneline -3
828b800 (HEAD -> master, origin/master, origin/HEAD) update homebrew formula to 0.11.2
f5fe9cf update changelog for 0.11.2
78c56a8 (tag: 0.11.2) fix tests broken by 2aacb24


~/src/git-brws$ rustup toolchain list
stable-x86_64-unknown-linux-gnu (default)

~/src/git-brws$ cargo build
error: failed to parse manifest at `/home/bgianf/src/Cargo.toml`

Caused by:
  no targets specified in the manifest
  either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present

@rhysd thanks a lot for creating this program. It certainly made my life easier.

Request

Open pull request from command line.

1. My remote is origin
2. I am on branch test which is ahead of master by 1 commit
3. git-brws --pr or a similar command should open pull request page

For example this page

talha131/tw-scripts-demo@master...jvm-dev

It has a create pull request button.

Currently nearest command is

$ git-brws master..test
$ git-brws master...test

But these pages do not have "Create Pull Request" button.

A comparison of URL shows that only git-brws master...test compares master against hash. If hash is replaced with branch name then "Create PR" button automatically appears.

I got the following error when executing on Windows 10. Any ideas?

C:\Users\admin\AppData\Local\nvim>git-brws
Error: Broken URL 'ssh://[email protected]:0x7FFFFFFFFFFFFFFF/neovim_config.git': invalid port number

C:\Users\admin\AppData\Local\nvim>cat .git/config
[core]
        repositoryformatversion = 0
        filemode = false
        bare = false
        logallrefupdates = true
        symlinks = false
        ignorecase = true
[remote "origin"]
        url = [email protected]:0x7FFFFFFFFFFFFFFF/neovim_config.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master
[credential]
        helper = store

C:\Users\admin\AppData\Local\nvim>

Repro

git brws -b ''

Expected results

Error because branch name cannot be empty

Actual results

Opens https://github.com/{owner}/tree/ and it causes 404 error in browser.

At the moment, git brws --pr is useful if I have a PR open for the branch or intend to create one.
Would you accept a PR to add --prs and maybe --issues to navigate to "Pull Requests" page and "Issues page"?

I've an azure devops repo which I checked our via ssh: git remote get-url origin returns <org>@vs-ssh.visualstudio.com:v3/<org>/<project>/<repo>. The current branch is feature/whatever and I'm in the repo root.

if I run git brws, I would have expected it to open the branch in the repo root, but my browser opens https://dev.azure.com/<org>/<project>. The real url should have been: https://dev.azure.com/<org>/<project>/_git/<repo>?version=GBfeature%2Fwhatever&path=/ (so the branch has to be url encoded with version=GB in front; project also needed a space URL encoded as %20, but that was already that way in the ssh url).

If I use git brws -c, the browser opens https://dev.azure.com/<org>/_git/<project>?version=GBfeature/whatever, so no URL encoded branch name and the project is in the wrong place.

If I do something similar in a repo which was checked out via https, I get this via git remote get-url origin: https://<org>.visualstudio.com/<project>/_git/<repo> and git brws throws an error: Error: Unknown hosting service for URL https://<org>.visualstudio.com/<project>/_git/<repo>. If you want to use custom URL for GitHub Enterprise ...

When -b is set, upstream should be detected based on the branch. But current branch is used always.

Repro:

$ git checkout -b tmp
$ git brws -b master

Expected:
It can open a page for master branch

Actual:
It causes following error since tmp does not set upstream remote branch.

Git command exited with non-zero status: fatal: no upstream configured for branch 'tmp'

git-brws assumes default remote name is "origin". However, Git 2.30 introduced new configuration clone.defaultRemoteName for specifying default remote name. git-brws should respect the configuration.

Ref: https://github.blog/2021-03-15-highlights-from-git-2-31/

Repro

cd git-brws
git checkout master
git commit --allow-empty -m hi
git brws README.md

Expected behavior

Opens https://github.com/rhysd/git-brws/blob/master/README.md

Actual behavior

Opens not existing page https://github.com/rhysd/git-brws/blob/xxxxxxx/README.md where xxxxxxx is a commit hash not pushed yet

Hi!
My company uses Stash for repository hosting. URL has format:

ssh://git@<hostname>:<port>/<owner>/<repo>.git

which corresponds to the web URL

https://<hostname>/projects/<owner>/repos/<repo>

It would be cool if git-brws supported such URLs

Howdy, just did a cargo build of the tool to test out simply browsing a file in the browser on its relevant branch, in Github.

I'm seeing times such as:

$ time git brws Makefile

real    0m4.878s
user    0m4.761s

And of course I tested this on a much smaller repo, and it is "instant"

I'm curious what the underlying mechanism is for I suppose finding which URL to open, and what could be a bottleneck within it regarding large repos?

I'm mostly interested in this tool for this single behavior, as it allows me to remove a vim plugin thats sole purpose is also this behavior, and I use it a lot in aforementioned repo

Thanks :)

I was just updating the AUR package I maintain for git-brws and noticed that it seemed to have a lot of dependencies for a seemingly simple tool. I ran cargo graph on the project and it produced this:

The details aren't especially important but it shows that a large amount of dependencies come in via reqwest (top center of the graph). Now don't get me wrong, reqwest is great, but it is full featured, high performance, and asynchronous. Given git-brws only needs to make a very small number of requests per invocation it seems that it may be overkill.

Perhaps a simpler HTTP client would be a better choice. I did some searching on crates.io and found minreq, which seems like it might be a good fit for git-brws needs.

What do you think? If this is something you'd be open to I could look into making a PR.