4 ms·

> Force pushing branches is what you do when you have pushed a branch that you expect to modify. Why would you do that? Because that's how Github and Bitbucket

by u801e 8y ago

> Force pushing branches is what you do when you have pushed a branch that you expect to modify. Why would you do that? Because that's how Github and Bitbucket have taught people to conduct PR's. I thought that Github and Bitbucket encouraged people to push up additional commits to fix issues in their PR. So, a typical PR will end up with a commit history like: Implement a feature method Add calls to new feature method Update to version 1.2.3 fixing missing semi-colon addressed comments one more thing now its working People who force-push are the ones who are trying to keep a clean commit history (meaning you don't have those extra 4 commits). So, your point about a PR being bad UX versus a rebase is correct, but not for the reason you state.

cyphar 8y ago
Almost no projects I've worked on that use GitHub ask people to push fixup commits. In fact, maintainers (like me) often have to ask people to squash their commits into reasonable chunks.
- mcguire 8y ago
  Usually, in my experience, you submit a pull request, add commits to fix things in the request, then when everything is copacetic, you squash the commits and submit a final pull request. You have to do a push -f to make that last request.
- Liskni_si 8y ago
  It's not the project that asks people to push fixups, it's that GitHub, as opposed to e.g. Gerrit, makes it hard to see what changed (how your comments were addressed) after a force push, so it's best that people only add commits. Ideally they'd use git commit --fixup=<sha> -p, and then git rebase --autosquash when the maintainer approves the merge, but few people care. (And what I'm saying isn't really accurate any more since GitHub does show force-pushes in the pull request UI these days and one can run git range-diff on that. But this wasn't possible last year.)
- eximius 7y ago
  I see this in OSS a fair bit. But for any private repo, I see the fixup commits.

by u801e 8y ago

cyphar 8y ago

Almost no projects I've worked on that use GitHub ask people to push fixup commits. In fact, maintainers (like me) often have to ask people to squash their commits into reasonable chunks.

mcguire 8y ago
Usually, in my experience, you submit a pull request, add commits to fix things in the request, then when everything is copacetic, you squash the commits and submit a final pull request. You have to do a push -f to make that last request.
Liskni_si 8y ago
It's not the project that asks people to push fixups, it's that GitHub, as opposed to e.g. Gerrit, makes it hard to see what changed (how your comments were addressed) after a force push, so it's best that people only add commits. Ideally they'd use git commit --fixup=<sha> -p, and then git rebase --autosquash when the maintainer approves the merge, but few people care. (And what I'm saying isn't really accurate any more since GitHub does show force-pushes in the pull request UI these days and one can run git range-diff on that. But this wasn't possible last year.)
eximius 7y ago
I see this in OSS a fair bit. But for any private repo, I see the fixup commits.