hub pull-request does not populate list of changes

[skrobul]

My workflow is relatively common - one 'main' repo on the organization account, several contributors with their public forks of the repo. I am usually working on the features in separate branches that I push into my public fork, then using hub I open pull requests.

Unfortunately for some time now, hub does not pre-populate pull request message with list of commits. This was very useful functionality, without it I have to open separate terminal window with git log just to see what has been changed in this particular feature branch. It could be something with my configuration, but I am having difficulties trying to find what's wrong. Is this common issue?

My setup:

• upstream remote represents main organization repository
• origin remote represents my individual repository

After I push all my commits to origin/feature-branch and issue hub pull-request, my editor opens and displays following pre-populated message:

# Requesting a pull to upstream:master from skrobul:feature-branch
#
# Write a message for this pull request. The first block
# of text is the title and the rest is description.

Please note that it kind of works, I can write my own message and submit pull request without problem, it's just the list of commits that is missing from the message. Correct me if I'm wrong, but it looks like hub should insert commented list of commits.

$ hub --version
git version 2.1.3
hub version 2.2.0-preview1

$ git remote show origin
* remote origin
  Fetch URL: git@github.mycompany.com:skrobul/salt-marek.git
  Push  URL: git@github.mycompany.com:skrobul/salt-marek.git
  HEAD branch: master
  Remote branches:
    master                                     tracked
    feature-branch                             tracked
  Local branches configured for 'git pull':
    master                 merges with remote master
  Local refs configured for 'git push':
    master                       pushes to master                       (fast-forwardable)
    feature-branch                  pushes to feature-branch                  (up to date)

$ git remote show upstream
* remote upstream
  Fetch URL: git@github.mycompany.com:myorg/salt-master.git
  Push  URL: git@github.mycompany.com:myorg/salt-master.git
  HEAD branch: master
  Remote branches:
    master                                           tracked
    refs/remotes/origin/feature-branch               stale (use 'git remote prune' to remove)
  Local ref configured for 'git push':
    master pushes to master (up to date)

Any ideas how to fix/troubleshoot this?

[mislav]

Hi thanks for the detailed report 🙇

I think this line is indicative of the problem:

Requesting a pull to upstream:master from skrobul:feature-branch

It reports the base as upstream:master when in fact should be myorg:master (using the "owner:repo" GitHub notation). Was it like that or did you change it when reporting to redact the name of the org?

It definitely seems like it's trying to fetch the log for the wrong base..head range. Maybe this is a regression since the Go rewrite.

[mislav]

This is on GitHub Enterprise, right? Also, what is your git config push.default thanks

[skrobul]

Sorry, yes, I overdid it when redacting stuff. The line says:
# Requesting a pull to myorg:master from skrobul:feature-branch

And yes, that's correct - it's GitHub Enterprise. My push.default is set to current. You can see full gitconfig here. The gitconfig.local contains only stuff that is likely not relevant - setting up different email + API tokens for Pivotal tracker integration.

Not sure if it helps, but later today I will try downgrading to hub 1.x and see if that happens again. Will keep you posted.

[skrobul]

OK, I've just downgraded hub to 1.12.2 and it behaves exactly the same way. The only minor difference I noticed is that it does not remove .git/PULLREQ_EDITMSG if I abort pull request by not providing the message.

[skrobul]

Just confirmed my worst suspicions... Historically, I have been forking the organization repo through WebUI, then cloning my fork locally. Once the clone was successful, I was adding another remote called upstream that represented organization repository I originally forked from. Therefore, for most of my projects I have:

• remote origin pointing towards my forked repo
• remote upstream pointing towards organization repo

While trying to open the pull requests (as per above), the hub did not populate messages. Few minutes ago I decided to try something new - swap the remote names, so that

• origin represents the organization repo
• and mareks_fork represents my fork.

Surprisingly, it worked and I could see the changes list immediately after running hub pull-request.

Could it be that base is hard-coded somewhere?

[mislav]

Your original naming scheme should have been supported as well. Because of this line:

Requesting a pull to myorg:master from skrobul:feature-branch

it's evident that base and head for the PR were picked correctly. It's just, for some reason, that fetching the log of commits failed. I have to investigate this.

[owenthereal]

The only minor difference I noticed is that it does not remove .git/PULLREQ_EDITMSG if I abort pull request by not providing the message.

It may be a regression. But if you don't provide the message, it doesn't matter if the file is there or not? What matters though is if you provide the message and abort the pull request, the file shouldn't be removed since the next pull request command will pick it up.

[skrobul]

@jingweno absolutely. It does not matter for me, just noticed the difference between two versions that may be somehow related. The file does not get removed when message is non-empty, which is expected behavior.

[skrobul]

Came in to work this morning and noticed one more detail. My original assumptions were bit off - years ago, the repo in question was forked from my individual account to organisation account, not the other way around as I indicated in my original comment. So I tried to reproduce the problem on a repo that has been forked from org repo into my own account and commit messages are populated properly.

[hisavali]

@skrobul Did you managed to pre-populate message? May I request you to provide gist of it?

[skrobul]

@hisavali yes, after I swapped origin with personal remote, the commit messages got prepopulated as expected. After the swap, the base remote is named origin and the repository I'm merging from can be named anything.

I don't have any specific example on hand, but the message was essentially the commented output of git log

[mislav]

@skrobul I'm glad you solved it and thanks for the update. Our branch detection isn't perfect right now. We'll work on improving it in future releases. In the meantime, I'm closing this because we're aware of this issue through other reports. #928 #877 #789 #461