4 ms·
If you made one commit after this sequence of events 1. Worked 2. Grabbed a coffee 3. Worked again You are falsifying history. One commit or more per butt-i
by avgcorrection 4y ago
If you made one commit after this sequence of events
1. Worked
2. Grabbed a coffee
3. Worked again
You are falsifying history. One commit or more per butt-in-seat mini session.[1] Anything else is borderline fraudulent.
[1] Or per balls-of-feet in front of your standing desk, if that is how you roll.
- rileymat2 4y agoI'd imagine the human psychology of this debate is quite a bit more complicated.
- MereInterest 4y agoFalsifying history isn't wrong in itself. Falsifying a shared history is, because it breaks other copies of the repo. So long as a branch exists only in a single repo, then the history of that branch can be rewritten without issue. But a shared branch should never be rewritten, because you'd need to copy the alterations into all copies of the repo. I take issue with tools that prioritize rebasing, because they usually make this distinction between rebasing a local branch and rebasing a shared branch. For example, GitHub's "Squash and Merge" or "Rebase and Merge" options break the shared history between the remote copy of the repo and my local copy. After such an operation, I cannot merge from main into my development branch, and must instead rebase my development branch onto main.
- atq2119 4y agoTo be fair, once you're developing on a project with enough commits/day, you no longer have a real choice if you want an overall linear history. You will have to cherry-pick to main somehow. Some people want to rather merge instead, but in my experience few people have the discipline to develop in large enough PR granularity to make the resulting merge commits meaningful and not polluting history while also keeping the non-merge commits meaningful by doing rebases while the change is still in review.
- charcircuit 4y agoI disagree. Every commit should be an atomic change that doesn't break the build including both compilation and it running properly. Doing what you are suggesting makes bisects near impossible, wastes extra time in code review, and wastes the time of people looking at the history because they have to comb through half baked ideas which they do not know if they actually work or were tested.
- avgcorrection 4y agoYou’ll be happy to hear that I wasn’t being serious.
- thayne 4y agoI can't tell if this is sarcastic or not.
- avgcorrection 4y agoSarcastic. :) I dislike the “never change history” attitude. One is always curating history by deciding when to commit instead of dumping the whole undo tree.