10 Matching Annotations
- May 2020
# Two commits are considered the same if they have the same tree and # the same commit and author metadata. This is how we re-identify # commits after their hash IDs have been rewritten.
Having to rebase and cleanup the commits while actively working on something is time and attention consuming.
I'm not sure how I feel about that. Usually I'd say it's worth it to do it periodically, even while you're working on it. Just not obsessive compulsively to the point that it is distracting from actual work.
which might or might not be useful depending on what is the content of the commit.
Just to make this clear, I'm on the side that adding strict rules doesn't necessarily improve a situation. Especially with something that is subjective like a commit message.
These two are in my opinion the most problematic — the basically go against each other. Typically, I try to work in increments over a feature and commit when I reach whatever techinical milestone I want to "checkpoint" at. It can also be out of the need to expose some idea or architecture and push it.
Good commit hygiene in general is a tough thing to enforce. It requires manual labor and descipline, from both the author and the reviewer.
If we can encourage people to create clean commits as they go, the example as you showed above should be far less common, because cleaning up such history as an after-math is most of the time almost impossible.
- it depends
- commits: when/how often to commit
- requires great effort/time/resources
- good commits
- do it right/well the first time because it may be too hard to clean up/fix later if you don't
- good commit messages
- time wasters
- too many rules/policies not necessarily helpful/a good thing
- iterative process
- requires discipline
- good policy/practice/procedure
- Apr 2020
Test on more recent rubies