4 ms·

$ git fetch url-or-remote their-branch-name:my/better-branch-name $ git checkout my/better-branch-name $ hack, commit, etc

caf 13y ago
I'm aware you can do that with native git, of course - but that leaves the original pull request on github appearing "unapplied", doesn't it? I meant that it would be useful to add a function for that workflow in the github UI.
- jedbrown 13y ago
  If you edit commits in the branch, then yes, it appears as declined in the UI, which looks hostile when they are notified. I write a friendly message every time I do this, but it sucks to have to give that explanation and the UI metadata is still wrong. I asked for this on bitbucket, though it's currently on hold [1]. If you don't edit the existing commits, then it will show up in the github/bitbucket UI as merged when you eventually merge, regardless of what games you play with branches. [1] https://bitbucket.org/site/master/issue/6704/supersede-pull-request https://bitbucket.org/site/master/issue/6704/supersede-pull-...
  - plorkyeran 13y ago
    One way I've worked around this is to merge the original pull request, then immediately force-push the fixed version. Still doesn't fix all of the UI metadata, but at least the pull request gets marked as merged.
    - jedbrown 13y ago
      Only works when you have push access to the repository that is the source of the PR. Normally maintainers don't have access to the repositories for all contributors.
      - plorkyeran 13y ago
        Er, no? You merge the unfixed version via the web UI (to get the PR marked as merged), then immediately force-push the fixed version to your own repo, not their's.
        jedbrown 13y ago
        Oh, I thought you meant updating the pull request by force-pushing on their branch. Your solution is racy, thus only acceptable for projects small enough that the likelihood of someone pulling during that window is sufficiently low.
        plorkyeran 13y ago
        It's definitely not an option for very large projects, but projects small enough to have a very low chance of someone pulling in a several second window describes the vast majority of projects (and in general by the time it gets unsafe I'd expect fixing up incoming pull requests to be impractical time-wise anyway).

caf 13y ago

I'm aware you can do that with native git, of course - but that leaves the original pull request on github appearing "unapplied", doesn't it? I meant that it would be useful to add a function for that workflow in the github UI.

jedbrown 13y ago
If you edit commits in the branch, then yes, it appears as declined in the UI, which looks hostile when they are notified. I write a friendly message every time I do this, but it sucks to have to give that explanation and the UI metadata is still wrong. I asked for this on bitbucket, though it's currently on hold [1]. If you don't edit the existing commits, then it will show up in the github/bitbucket UI as merged when you eventually merge, regardless of what games you play with branches. [1] https://bitbucket.org/site/master/issue/6704/supersede-pull-request https://bitbucket.org/site/master/issue/6704/supersede-pull-...
- plorkyeran 13y ago
  One way I've worked around this is to merge the original pull request, then immediately force-push the fixed version. Still doesn't fix all of the UI metadata, but at least the pull request gets marked as merged.
  - jedbrown 13y ago
    Only works when you have push access to the repository that is the source of the PR. Normally maintainers don't have access to the repositories for all contributors.
    - plorkyeran 13y ago
      Er, no? You merge the unfixed version via the web UI (to get the PR marked as merged), then immediately force-push the fixed version to your own repo, not their's.
      - jedbrown 13y ago
        Oh, I thought you meant updating the pull request by force-pushing on their branch. Your solution is racy, thus only acceptable for projects small enough that the likelihood of someone pulling during that window is sufficiently low.
        plorkyeran 13y ago
        It's definitely not an option for very large projects, but projects small enough to have a very low chance of someone pulling in a several second window describes the vast majority of projects (and in general by the time it gets unsafe I'd expect fixing up incoming pull requests to be impractical time-wise anyway).