it’s improper to suggest that we regularly rebase the git history
The point I want to make is that outside of "critical regions" in time where multiple persons read/write to the same branch (i.e. always for the main branch, and during collaboration on a branch, and during review/evaluation of a branch that only you work on, but not on all remote branches in general), we should rebase as crazily as we want, if it benefits our individual workflows.
The story I heard repeatedly is "don't rewrite history, it's bad," but in fact, there's two arguments that get muddled up, being "don't create unnecessary conflicts on shared branches," and "don't use these tools, they're too advanced for me." -- both of which are valid points, but neither of which warrant blacklisting rebasing e.g. at the end of a branch'es lifetime, immediately before it gets merged back, and possibly even before that, as long as you don't create conflicts when someone else is working, and as long as you don't force the use of tools on others.
I don’t see a strong reason to push a commit without a well-written commit message, intending to fix it later. That just sounds lazy to me (which I guess most programmers are 🤷)
It may be laziness, or it may be priorities, I'm not the one to judge. When commits like the ones I posted end up on the master branch, that is both lazy and careless. But if you end the day half-done with something, and you want to back up your work, pushing a WIP commit to your remote branch, before you've asked others to sync, and then rebasing it the day after, is not a crime in my book. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks a lot for your feedback. :)
The point I want to make is that outside of "critical regions" in time where multiple persons read/write to the same branch (i.e. always for the main branch, and during collaboration on a branch, and during review/evaluation of a branch that only you work on, but not on all remote branches in general), we should rebase as crazily as we want, if it benefits our individual workflows.
The story I heard repeatedly is "don't rewrite history, it's bad," but in fact, there's two arguments that get muddled up, being "don't create unnecessary conflicts on shared branches," and "don't use these tools, they're too advanced for me." -- both of which are valid points, but neither of which warrant blacklisting rebasing e.g. at the end of a branch'es lifetime, immediately before it gets merged back, and possibly even before that, as long as you don't create conflicts when someone else is working, and as long as you don't force the use of tools on others.
It may be laziness, or it may be priorities, I'm not the one to judge. When commits like the ones I posted end up on the master branch, that is both lazy and careless. But if you end the day half-done with something, and you want to back up your work, pushing a WIP commit to your remote branch, before you've asked others to sync, and then rebasing it the day after, is not a crime in my book. :)