10 ms·

Git rebase is great. Honestly I think the argument that "if you have to push -f that means rebase is wrong" is making a huge assumption about how people use bra

by zemo 7y ago

Git rebase is great. Honestly I think the argument that "if you have to push -f that means rebase is wrong" is making a huge assumption about how people use branches and why people are force pushing branches. 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. If your immediate reaction is that "rebase is bad UX", ask yourself whether or not pull requests are good UX. I honestly think rebase is great, but that pull requests are extremely bad UX, and the UX blame is misplaced on rebase when where it really belongs is on pull requests.

paulddraper 7y ago
I should add that `rebase` in no way requires `push -f`, if these are private, unpublished changes.
u801e 7y 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 7y 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 7y 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 7y 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 zemo 7y ago

paulddraper 7y ago

I should add that `rebase` in no way requires `push -f`, if these are private, unpublished changes.

u801e 7y 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 7y 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 7y 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 7y 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.