Hub: New pr command is confusing

[JelteF]

Having both a pull-request and a pr command is super confusing. They both mean the same but do different things. I even created a git alias before from pr to pull-request which suddenly didn't work anymore. I doubt I'm the only one that did this.

Why is pr checkout not a subcommand of pull-request instead? You could even let pr bare do the same as pull-request if you want to keep the shorter variant.

[elliott-beach]

I concur.

[mislav]

Thanks for bringing this up. Yes, it's confusing in the current transitional period. However, my goal is to eventually deprecate pull-request in favor of hub pr (which is now only in beta). The idea of hub pr is that it will have subcommands to checkout, create, list, or edit pull requests.

I didn't want to extend the hub pull-request command with subcommands because that would be too verbose to type. I also won't be changing/breaking hub pull-request for a long time to maintain backwards compatibility since many people already wrote automated scripts wrapping pull-request.

[zaquestion]

@mislav Have you had anymore thoughts on the pr command, specifically for its sub commands? I've implemented a similar feature on lab (referenced above). Personally the commands don't feel right. It seems like hub VERB NOUN would flow better (ie hub list pr, hub checkout <pr #>)

[grimm26]

The more important question is how I get pr out of the way now so my pr alias to pull-request in gitconfig works again

[mislav]

@grimm26 The hub pr command is here to stay and will be expanded with extra features. The goal is to eventually replace hub pull-request. While it exists, a pr alias won't be possible, sorry. It's core git behavior that an alias that matches an existing command name isn't respected.

[grimm26]

@mislav well, I put this in my .zlogin to solve this. Hope it helps someone else, too:

git () {                                                                                                                                                                       
  if [ "pr" = "$1" ]; then                                                                                                                                                       
    hub pull-request                                                                                                                                                           
  else                                                                                                                                                                           
    hub "$@"                                                                                                                                                                   
  fi      
} 

[mislav]

@grimm26 Thank you for sharing your workaround! 🎉

[tsmanner]

I've run into this in both zsh and bash in my work environment. I wrote a pair of shell functions to wrap it up into a function to try and match the other commands. I then have git aliased to _gh.

For zsh:

_gh() {
  local -a args
  local nargs
  args=("$@")
  nargs=$#args
  for i in {1..$nargs} ; do
    if [ "${args[$i]}" = "pr" ] && [ "${args[$i+1]}" = "create" ] ; then
      args[$i]="pull-request"
      args[$i+1]=""
    fi
  done
  hub $args
}
compdef _hub _gh=hub

And for bash:

_gh() {
  args=("$@")
  for i in "${!args[@]}" ; do
    if [ "${args[$i]}" = "pr" ] && [ "${args[$i+1]}" = "create" ] ; then
      args[$i]="pull-request"
      args[$i+1]=""
    fi
  done
  hub "${args[*]}"
}

This is a less performant, but more general solution, providing the git pr create command while still allowing arbitrary flags to be passed to git. The zsh solution also includes a compdef line to point _gh to the hub completions (available here)

[sprynmr]

Any update on some sort of create command on pr?

[mislav]

@sprynmr No; you should continue using hub pull-request for now.