[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