I am firmly convinced that having a readable semantic Git history, with commits broken into relatively small well-named pieces instead of "big bang" everything-at-once commits, is vital to the long-term maintainability of a project.
Being able to quickly identify when, why, and how a given chunk of code was changed, and see how that code has evolved over time, has been critical as I've tried to track down bugs and understand the design decisions and context behind codebases.
A good commit message should include an issue tracker ID tag, a good short description, and a much longer descriptive section if appropriate.
I don't think the author would disagree with any of this. I think the author is more opposed to what I term "improving history"
I Think everyone should know how to rebase, resolve conflicts, and use git absorb --and-rebase to erase trivial typos from history.
It may be best to spend the extra time keeping history clean in open source projects. But then again, devs in Open source can in theory always be reached later on with questions about a line of code they wrote.
I have to agree that the actual code's readability is more important.
What we really want is arbitrary comments on any commit sha/line, and complete and utter freedom to edit commit messages before merging to master. (Git notes subcommand almost works, but should be unified with GitHub line comments.
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.
I'll have to disagree strongly here.
I am firmly convinced that having a readable semantic Git history, with commits broken into relatively small well-named pieces instead of "big bang" everything-at-once commits, is vital to the long-term maintainability of a project.
Being able to quickly identify when, why, and how a given chunk of code was changed, and see how that code has evolved over time, has been critical as I've tried to track down bugs and understand the design decisions and context behind codebases.
A good commit message should include an issue tracker ID tag, a good short description, and a much longer descriptive section if appropriate.
I don't think the author would disagree with any of this. I think the author is more opposed to what I term "improving history"
I Think everyone should know how to rebase, resolve conflicts, and use
git absorb --and-rebaseto erase trivial typos from history.It may be best to spend the extra time keeping history clean in open source projects. But then again, devs in Open source can in theory always be reached later on with questions about a line of code they wrote.
I have to agree that the actual code's readability is more important.
What we really want is arbitrary comments on any commit sha/line, and complete and utter freedom to edit commit messages before merging to master. (Git notes subcommand almost works, but should be unified with GitHub line comments.