"Open in github..." menu options

When the remote is on github (and it usually is):

1. Put an "Open in github..." line on the remote/branch menu:

2. Put "Open in github..." lines on the repository menu, and add a default keystroke (⇧⌘R, ⇧⌘O ) for the origin remote:

   

Either of these would just open a URL in the default browser.

Oww yes, and on the GitHub branch page there will be a link to corresponding PR 👍 👍

Thank you for keeping this alive! I want to contribute, so I picked this issue to start with.

It works now for Github from the remote/branch menu. But then I started to think about it:

• How do we handle multiple remotes? • Should other hosts like Bitbucket be supported as well?

Possible solution: If there is only one remote, show it with "Open in $…" where $ is the name of the host. If there are multiple remotes, provide a submenu with all available remotes which can be accessed by a browser.

What do you think?

Adding bitbucket makes sense to me, and probably isn't much more code and/or complexity.

I think there are privileged/frequent remotes that should go on menu, and have a shortcut, for sure origin, and possibly upstream.

If you wanted to have other remotes on a submenu, maybe something like:

---------------
Open in Terminal
Reveal in Finder
---------------
Open origin on $       sh-cmd-O
Open upstream on $     sh-cmd-U
Open on website > (list of other remotes on either bb/gh)

I like that, thanks for the hint! Hopefully I get this done soon

@mangerlahn

My intuitive take would be to start this off with just an entry in the contextual menu for a remote to open that particular remote.

I’d also suggest that GitX should not totally hard-code the known hosting services but, in addition to a default list, have a user default (possibly not exposed in the UI to begin with) with a list of remote name/git URL/http URLs that lets users augment this with their own favourite / private repos.

Personally, I am not totally convinced that hard-coding branch names and allocating standard menu items with keyboard equivalents for them is a good tradeoff between general usefulness and littering the UI with menu items that are useful for some setups only.

How do you plan to get the data about the remotes? Can we do this in a way that does not run a git command? (Which to me would seem a weird thing to do when validating menu items.)

with a list of remote name/git URL/http URLs that lets users augment this with their own favourite / private repos.

Grab the data from the .git/config "remote" section would be my suggestion ? No need to have another "user default" for which we have no storage handy. Then if it looks like a GH or BB URL, show a "Open in browser…" menu item.

How do you plan to get the data about the remotes? Can we do this in a way that does not run a git command?

Use libgit2 😉. Also, there should already be a list of remote "objects" available on PBGitRepository, so I don't think either would be profitable...

@ssp You've got a point on simplicity. However, a default shortcut for origin / upstream would be quite handy. Since the menu is created entirely dynamic I thought of only displaying the available options instead of disabling the other ones. Most (simple) repos have only the remote named origin anyway.

I agree that hard coding is not the best idea. The problem is that some urls like from Bitbucket need some customisations in order to be opened by the browser correctly. Bitbucket urls have the following scheme: https://username@bitbucket.org/... The username and @ symbol have to be omitted. So some sort of "parsing" has to be done here.

I indeed use a Git command currently. I also find this a bit strange, but I wasn't able to figure it out otherwise. However I would be happy to change that! I had no performance problems with that on my machine, but I can't guarantee that for everyone.

@tiennou I use git remote -v to list all remotes and then filter though that list to get the remote names and URLs.

The remotes array returned by PBGitRepository only contains the remote name (e.g. origin).

@tiennou my point was that while many of us are using github, I wouldn’t want to hardcode GitX to a single commercial service and enable this feature to work in a way that allows for other services in a sufficiently flexible manner.

@mangerlahn +1 for the »parsing«. My hope would be that we can find a simple string-based (say a regex) way to encode this so this can be confoguration only rather than require code.

I don’t think main menu items should be dynamically added (while contextual menu item should be), so I wouldn‘t be a fan of creating them that way.

@ssp Yes it would be neat to provide the most flexibility here. Is a plist with default values the way to go here? On the other hand, this is a very small feature and there are not that many services out there. I guess most users wouldn't even look for extending the list of supported services, especially not in something like a plist. And if another service becomes huge, it would be added as default to that list as well, so some work is always needed. Its basically the same amount of work/time (couple of minutes) to hardcode them in.

For the interface: We could cram all remotes into a submenu, as @claybridges pointed out. So in the end there would be one menu item in the context and main menu which unveils all possible remotes.

• I don't think a plist is worth the effort. It's more trouble, and less straightforward, than putting a couple of URL regexs (or such) in the UI code, and I don't see any benefit. As for wiring specific websites, github arguably covers 90% of the cases here, github + bitbucket 98%, I'm not sure why being more general is important.

• The origin branch is also probably a 90%+ common case. Mapping that to a keystroke sure looks like a win to me. I do that a lot more than stash, for instance. I don't really care if it's on the menu or not, but it would help with discoverability. I think it combines well with terminal & finder as views on the repository.

• Even though I kind of suggested it above, I'm not sure I see much benefit to having all the branches listed on a submenu, given you can right click any one that you see, and open the website on that menu.

Would that be a good compromise?

I just realised that we would not have the problem of displaying multiple "Open in" items when they are context aware. They would then behave like, for example, the Fetch $ menu item, which is disabled when no remote is selected.

@mangerlahn That looks OK. Maybe you could make a throwaway WIP pull-request and we could play around with it? Might be easier to give feedback on.

@claybridges Already did that here 😏

Oh, jeez, hard to keep up on current events. :|

I had a bit of this prepared locally as well and made it available in #68.

My PR does not tackle the various menus but focuses on making things more configurable and recognising more URLs.

Since I'm only fluent in GitHub, I can't really comment on what's actually available on the other hosters out there. But anyway, here are my thoughts...

I find the plist-based approach too disparate/simple. If it's just about regex-ing some URLs, I'd prefer those be code. Also, since we're talking "hosters", what about parsing # symbols in commit messages (hence my point about fluency) ? What about having a "Open Pull Request in $hoster" ?

So, I'd prefer an approach that uses something along the lines of :

@protocol PBHostingService <NSObject>
- (NSURL *)webURLForRefish:(id <PBGitRefish>)refish; // rationale, you can now right-click open *anything*
@optional
- (NSURL *)pullRequestURLForRef:(PBGitRef *)ref;
- (NSString *)annotatedHTMLForCommitMessage:(NSString *)message;
@end

@interface PBHostingServices : NSObject
+ (id <PBHostingService>)hostingServiceForRemoteName:(NSString *)remoteName inRepository:(PBGitRepository *)repo;
@end

Obviously, I'm glancing over a few things (is there an easy way to know which branch a refish is on, and hence if it has a remote, or can it have many).

Apart from that technical point, I'd be pleased with a simpler "Open remote in $hoster" though 😉.

@tiennou that’s certainly an interesting idea that would allow a lot more features (although I am not sure there’s a way to implement all of them).

My line of thinking is that preferred hosting services should be a matter of configuration (as opposed to patching and re-building the application).

Not only because GitX has a fairly strong history of not releasing new versions, but for the practical reason that it should be possible to use this feature with repositories on private servers.

Right now I am wondering: For just opening the repository on the web, do we have use-cases at hand where regexes alone will not do? (Examples?) What about the further features the protocol you sketched would allow?

If regexes alone will not do, the protocol could still enable a string/regex configurable setup and then add other implementations for the special cases.

Quick request, if this is hard coded, can it also support gitlab?