Buttons for pulling and creating branches would be good though.
And break glass to `git reset --hard` would provide some nice ceremony.
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
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.
People altering the line ending of several files so that you cannot do any normal actions anymore.
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
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!
See also: Samir you're breaking the car!
(For today's 10000, that's a bloopers real of a professional racer that was done as a prank by a rival and which ended up causing him some problems)
Or I should say, I see the trap in the two or three most obvious variants which makes them even less effective because you create a Confused Deputy situation with the person you expect to sign off.
Example: If I file a PR to change a production flag, and I tell you what (I think) I just did, you're likely to approve my change because I've primed you to see what I wanted you to see, and you miss the same bug I missed. You're going to trust my judgement when the whole point of not allowing me to just push without a second pair of eyes is that you cannot trust my judgement 100.00% of the time. If I'm 99.9% trustworthy you're likely to stop looking at my ideas expecting to see a problem.
I believe if we don't send each other code we are more likely to get that 4th 9. But I could still be wrong thanks to the Primacy Effect mentioned above.
Gitlab premium can also require multiple approvals before a merge request can be merged.
Approvals don’t work, and I’ve already said as much. If approvals worked so well we wouldn’t have dual key systems at all.