51–57 of 57 posts
Earlier quoted context omitted.
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.
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 wh…
Earlier quoted context omitted.
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 wh…
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
It's easy for the original author to make changes to the PR, but not easy for the maintainer or a third party to make changes. The micro-pedantry associated with spelling errors, tweaking commit messages, and trivial spacing/formatting issues can be more work for everyone when communicated through comments on PRs with the original author expected to apply and re-roll.
That's only partially true. Pull requests on GitHub have to have an associated branch or fork in another repo. Even if you're not the original author, if you have access to it, you can do "git checkout" or "git clone", then you make the required changes and then on push the commits are automatically included in the pull request. The only problem is that the maintainers do not have write access to the forked repositor…