Rewrite in Python?

[paulirish]

Rewrite in Python?

[derimagia]

Last thing is git open issue. I see that it expects the branch to be the pattern (issues/#123) but is that pattern common or is it just made up for this? Do people usually run something like git fetch upstream pull/79/head:issues/#79 (with that pattern)? I personally don't have a standard

One thing we can do is just regex all numbers from the branch name. Also did we want options yet so this is being a flag just in case someone has a branch named issue?

[ffes]

I think you are right. Adding new features will probably be easier. It also add possibilities to do things like unit testing the functions that translate the URLs (now that would be very useful).

But I think some things need to be discussed before that port can started.

First of all, know that Python is not available for Windows users who use the default Git Bash! And this Git for Windows doesn't support adding packages out of the box. So that would vote against using to any other language than bash or perl.
I use Cygwin myself and Python run just fine on that. And WSL runs Python fine as well.
But people who are interested in things like this project, will probably be able figure out how to overcome the limitations of "Git for Windows".

But more important, what about the command line options that are available at the moment, and features that people ask for (or I would like to see ;-): Open PR (#47), git open #issue_number, open a file (#54), git open compareto (#64), --verbose or --debug (to see the final URL with or without opening the browser), etc.
Looking at the command line options, at the moment they are git open [remote] [branch] and git open issue. But what is the remote is named issue? What if the compareto PR is accepted as-is and you have a remote named compareto?

So I would suggest to think about the command line usage first, before the port is started.

[ffes]

@paulirish Which version of Python would you suggest?

[paulirish]

@ffes good feedback thanks.

I also work on diff-so-fancy and there we underwent a port from bash to perl, for similar reasons. Unfortunately perl is mostly out of range for a lot of contributors so our bus factor is pretty high there. :/

as far as features and CLI options.. i still prefer being really conservative on the feature scope. but if i'm going to lose that battle then i'd personally prefer moving to nodejs for the whole utility. i maintain a number of node-based CLI apps now and certainly many developers feel feel comfortable in that environment.

But you point out that python isn't a given in git bash. so if we're already making it hard for our windows users with a move to python (i was thinking 2.7..), i suppose i'd prefer going to nodejs.

wdyt?

[derimagia]

Looking through the code and some of the pull requests, I think there's a few issues here. One is that no one has access to all of the git hosts and because of this everyone is thinking in "patch it" mode instead of thinking in a bigger picture. Most of the hosts are pretty similar though, and I think a lot less string parsing is needed than there is currently. I also noticed some hosts had "features" built in that others didn't (like in gitlab hosted it looks like it opened it to your current directory). Essentially a lot of duplicated code.

I went a look and took a look at the script as a whole and reworked it: https://github.com/derimagia/dotfiles/blob/62e17bfcb9d6c73d83a91a9ca7a8ac82d7fdafcf/config/zsh/bin/git-open

Essentially instead of parsing every url based on the domain, it breaks it up into pieces and then does very minimal specific host items (Right now just bitbucket, but there could always be a catch-all git config item to

Now full disclosure, I didn't implement the "pr" code and I didn't implement bitbucket self-hosted as I don't have access to that, but I tested this on Github, Github Enterprise, Gitlab, Gitlab hosted, and bitbucket. I'm sure I'm missing some things here. I fixed a few issues I saw like supporting gitlab enterprise and gitlab's subgroups (aka not "owner" and "user" but just "path" instead)

I agree bash isn't the best for everyone and depending on what features you want to support another language is probably a good idea. I think the line I would draw would be if you wanted to add authentication of some kind or if you wanted to add a lot of "host specific" code. I do like how https://github.com/tj/git-extras is structured though. We can always make our own porcelain commands or have a git-open-pr command. I do think options should generally be passed with dashes though.

[paulirish]

@derimagia this is awesome. really appreciate you giving this a go and showing how it can be simplified so much. Also, I really agree with your assessment of the current state of complexity.

Today I got a little test suite going for the project, and its exercising most of the features and details people have requested: #78

Your simpler implementation does really well once some of the test expectations are adjusted: testrunner...derimagia+tests

The only two failures that I have are: 1) that git open issue doesn't work. and 2) gitlab special handling isn't done.

are you interested in sorting out these items? if so, I think it's worth it to take on your new revision.

[nwinkler]

Having had a quick look, I don't see support for Bitbucket Server in the above Gist. Bitbucket Server needs a somewhat clever/annoying change in the URL, adding projects and repos in the URL (see https://github.com/paulirish/git-open/blob/master/git-open#L92) - I did not see that in the Gist...

[ffes]

The rewrite @derimagia started in bash is indeed very nice to integrate. I see you already started it in a separate branch. In that case, do we need to a rewrite in Python?

If we decide to go that path, I have a personal need for the GitLab CE/EE integration, so I will gladly look into that.

[derimagia]

@paulirish I'll take a look to fix the remaining issues over the weekend - as @nwinkler mentioned it is also missing bitbucket server support - This is the only instance I don't have access to and I must have missed mentioning it in my comment above. If someone can give me input/output or a failed test for Bitbucket server I can take a look

@ffes The integration with Gitlab CE/EE, is that the fact that git/http are on separate domains? Trying to think of a clean way to support as much as possible - would one config option that replaces a (git) uri with a http(s) url work? That way this would also support suppling the scheme (Right now I just used https). Ideally there wouldn't be a need for provider-specific config but I understand we may need that anyway

[derimagia]

Another thing that I haven't done yet that wasn't supported was expanding insteadOf aliases, I mentioned that here with a solution: testrunner...derimagia+tests#diff-21e611831fd54f9104bb1bb2abf161eeR19. I read that that's only supported in git 1.7+ - how far back are we supporting w/ git? As far back as we can I assume? It can probably just fallback to the current method of getting the remote

[nwinkler]

@derimagia Here's some input/output for Bitbucket Server:

• Input: https://[email protected]/git/scm/ppp/rrr.git
• Output: https://mybb.domain.com/git/projects/ppp/repos/rrr

As you can see, it:

• Removes the scm
• Adds projects before the project name
• Adds repos before the repo name
• Removes the .git

For detecting that it's a Bitbucket Server, I've used the presence of the scm part in the Git remote URL, which always seems to be the case for Bitbucket Server.

Let me know if you need additional info.

[ffes]

@derimagia In the current implementation in master there are settings to recognize a separate ssh and web for GitLab CE/EE domains. See #56.

With your rewrite I don't need those GitLab settings anymore because at the office we use a default configuration. Great!

But for the "separate ssh/web scenario" those settings are needed. You need to know what the web url has to become based on the ssh domain you will find in the remote. Maybe @evoactivity can help better. He is the one who created that PR.

[derimagia]

@nwinkler Your example doesn't have scm at the root (bb.org/git/scm instead of bb.org/scm/), why's that? Are you trying to get compatibility with non-root installed git repos?

[paulirish]

Let's take the Bitbucket server convo over to #83 to simplify. i'll bbserver delete my comment here. :)

[paulirish]

Last thing is git open issue.

@derimagia the convention was new to me when it was requested. but i like the idea, at least.

I like the idea of making it flexible.. Since it's opt-in with the issue command, then just extracting any \d+ from the name and opening that up seems worthwhile.
I'm fine with breaking people that have branches named issue. :) Let's ignore that.

[paulirish]

Fixed based on the new revised implementation from @derimagia (PR #85)

Cheers