3 ms·

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 pur

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.

_kb 2y ago
And a `git push -f` on physically separated key switches that require two people to operate.
- rtkwe 2y ago
  Me at the end of a contentious code review: "TURN YOUR KEY SENIOR!" https://youtu.be/rLMCjuge6oE https://youtu.be/rLMCjuge6oE
  - hinkley 2y ago
    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)
- hinkley 2y ago
  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_ 2y ago
    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 2y ago
      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.
lukasgraf 2y ago
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

_kb 2y ago

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

rtkwe 2y ago
Me at the end of a contentious code review: "TURN YOUR KEY SENIOR!" https://youtu.be/rLMCjuge6oE https://youtu.be/rLMCjuge6oE
- hinkley 2y ago
  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)
hinkley 2y ago
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_ 2y ago
  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 2y ago
    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.

lukasgraf 2y ago

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