git-open
git-open copied to clipboard
paulirish
git open a particular file
I was just thinking it would be cool to be able to do something like:
git-open /path/to/file
and have the browser open that file in that branch that one was in ...
Yes, please!! That's the main reason I checked out this project.
git open ../path/to/file
Even just an option to echo the URL to stdout instead of actually opening in the browser would be helpful... Then we could write our own functions and aliases that basically just did open $(git open)/$1...
Just discovered, that git-open has such an option already!
# Allow printing the url if BROWSER=echo
if [[ $BROWSER != "echo" ]]; then
exec &>/dev/null
fi
So I was able to write my own git-open-path script that wraps that and opens the given file name:
xdg-open "$(BROWSER=echo git open)/blob/$(git symbolic-ref --short HEAD)/$@"
Brilliant, TylerRick!
Note that the '/blob' path works for both GitHub and GitLab, so this is already a pretty general-purpose command/script. (I put it into my custom .bashrc rather than making a separate script file.)
Would still be great to have git-open --file path/to/file built into git-open even if not git-open path/to/file, which might be too hard to disambiguate from the remote name or branch name.
Right, that seems like the main blocker to implementing — how to invoke this option. :disappointed:
I would vote for git-open path/to/file personally because it's so much nicer to type, but like you said, how would we disambiguate from remote name or branch name? We might consider "." or "/" characters to mean it's a file but even remotes or branches could probably contain those characters.
Personally I'd sooner relegate branch or remote to special flags, like git-open --branch branch, than I would add git-open --file, because I typically only have one remote, and I typically only care about the branch I have currently checked out.
git itself has a number of commands which accept both a commitish/branch as well as a file. Could we model the interface for this command after git's?
Take, for instance`:
$ git log foo
fatal: ambiguous argument 'foo': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git
In other words, maybe if it's unambiguous, we let the first argument be either one, and if it's ambiguous, we require a `--`.
You might also want to combine them, as you can with `git log`, which would also solve the problem of disambiguation:
git-open master path/to/file git-open @ path/to/file # @ being a handy shorthand for HEAD