4 ms·

When mentoring a junior, I noticed he had an alias `gpf`, which he apparently picked up from another developer. I had a serious conversation with him, explaini

When mentoring a junior, I noticed he had an alias `gpf`, which he apparently picked up from another developer. I had a serious conversation with him, explaining that I'm not in the habit of telling him how to configure his shell, edit or general work environment. But an alias for `git push -f`, that I cannot condone. When you're doing that, the two seconds it takes to type it out should be rather low on the list of priorities. So we had a good talk, and he genuinely understood the point I was trying to make. When I was about to leave, he looked at me sheepishly and asked: "So I guess you want me to remove this one too?" gacpf - git add . && git commit --amend && git push --force

hinkley 2y ago
On my last project I was the only person who had --force permissions on bitbucket. In six years I used it twice on purpose, and once on accident (and then once again to undo the mistake). If you want to do a push -f to a branch that only you are working on to finish a rebase -i to make the commits you did in haste make sense, then go for it. But nobody should be forcing to master unless it's to undo a really big fuckup. One was merging a PR with giant files accidentally attached, the other was re-exporting from perforce because they totally fucked 'git blame' and I wasn't having any of that.
- consp 2y ago
  > undo a really big fuckup People altering the line ending of several files so that you cannot do any normal actions anymore.
tux3 2y ago
Oh, I have practically the same alias. You might be surprised at this if you use Git in append only mode, making "fix 1", "fix 2", ... commits on a branch when you find a problem in a previous commit Another workflow is to keep each commit self-contained, rebase the series when you make changes, and send the v2, v3, ... of your pull request with push --force Of course, if you do this on a shared branch that other people also want to commit on, you may want to pick a desk close to the exit, and far away from any windows
- aunderscored 2y ago
  Have you considered fixup commits? On shared branches they work very well. Either autosquash before pushing, or as part of your final PR prep
  - tux3 2y ago
    On shared branches I prefer to send pull requests, that way I can rework my draft and respond to review comments until it's ready, without pushing undercooked commits directly on the shared area What lands on the shared branch has a meaningful history, that has helped me more than once to understand the context in which an old change was made, when running git blame many months later. I feel like it should be as easy to review the history as it is to review a PR. Squashing makes this a bit harder for me. Especially when autosquash loses long commit messages. But I like to use git-absorb to automatically create fixup commits, it generally works pretty well and saves me a little bit of tedium each time!
BiteCode_dev 2y ago
Timd to show jujutsu to the intern

hinkley 2y ago

On my last project I was the only person who had --force permissions on bitbucket. In six years I used it twice on purpose, and once on accident (and then once again to undo the mistake). If you want to do a push -f to a branch that only you are working on to finish a rebase -i to make the commits you did in haste make sense, then go for it. But nobody should be forcing to master unless it's to undo a really big fuckup. One was merging a PR with giant files accidentally attached, the other was re-exporting from perforce because they totally fucked 'git blame' and I wasn't having any of that.

consp 2y ago
> undo a really big fuckup People altering the line ending of several files so that you cannot do any normal actions anymore.

tux3 2y ago

Oh, I have practically the same alias. You might be surprised at this if you use Git in append only mode, making "fix 1", "fix 2", ... commits on a branch when you find a problem in a previous commit Another workflow is to keep each commit self-contained, rebase the series when you make changes, and send the v2, v3, ... of your pull request with push --force Of course, if you do this on a shared branch that other people also want to commit on, you may want to pick a desk close to the exit, and far away from any windows

aunderscored 2y ago
Have you considered fixup commits? On shared branches they work very well. Either autosquash before pushing, or as part of your final PR prep
- tux3 2y ago
  On shared branches I prefer to send pull requests, that way I can rework my draft and respond to review comments until it's ready, without pushing undercooked commits directly on the shared area What lands on the shared branch has a meaningful history, that has helped me more than once to understand the context in which an old change was made, when running git blame many months later. I feel like it should be as easy to review the history as it is to review a PR. Squashing makes this a bit harder for me. Especially when autosquash loses long commit messages. But I like to use git-absorb to automatically create fixup commits, it generally works pretty well and saves me a little bit of tedium each time!

BiteCode_dev 2y ago

Timd to show jujutsu to the intern