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.
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:
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.
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
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!
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.
The cd automatically pulls if it's a git repo.
The acp is shorthand for "add+commit+push" with sk as a fuzzy finder for a commit message editing (vim integrations).
[Sorry for ruining the fun in an industrial setup, the big red button is the emergency stop. If someone is in danger, you just push the big red button to stop the machine.]
Thanks for the mention - I've always thought Stream Decks were kind of interesting, but overkill. It turns out a macro keyboard is what I really wanted.
Any keyboard with macro functionality is capable of one click operations. Any IDE is capable of one click operations. Any shell with history is capable of two-click operations.
It's just a keyboard button. It can do the same harm any developer can already do.
In the early 90s, Gateway had a keyboard called "Anykey" that let you program macros into the keyboard firmware. We programmed several DOS commands into ours. It had two full sets F1-F12 of function keys, both along the side like an old Model F, and along the top. So the F-keys on the side we used for DOS macros.
The Logitech G15 keyboard which has about 2 major versions, is capable of some nifty keystroke / macro functionality too. I have one of them somewhere.
I already have tons of aliases for git, One of my fav's when I developed on a Mac was to also take a photo every time I pushed. I forgot about it for about a year, going into that archive was hilarious.
Buttons for pulling and creating branches would be good though.
And break glass to `git reset --hard` would provide some nice ceremony.