[afandian]

Fun idea, but adding and committing is the time when I want to be going slow and paying the most attention! What files did I change, were all the changes on purpose, have I described all of the changes.

Buttons for pulling and creating branches would be good though.

And break glass to `git reset --hard` would provide some nice ceremony.

[lukasgraf]

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]

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]

> undo a really big fuckup

People altering the line ending of several files so that you cannot do any normal actions anymore.

[tux3]

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]

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]

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]

Timd to show jujutsu to the intern

[_kb]

And a `git push -f` on physically separated key switches that require two people to operate.

[hinkley]

Do you know of any software systems that do 'double key lockout' like this? I've wanted one for a long time but I am having a failure of imagination on how to implement it.

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.

[_ikke_]

Systems that use shamirs secret sharing, like openbao, require multiple operators to unlock the secret engine.

Gitlab premium can also require multiple approvals before a merge request can be merged.

[hinkley]

Yeah I’ve used HSMs that have those. But I’m talking about things like running deployments, changing production configurations, or rebooting servers.

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.

[rtkwe]

Me at the end of a contentious code review: "TURN YOUR KEY SENIOR!"

https://youtu.be/rLMCjuge6oE

[hinkley]

The only way to win is not to play.

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)