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 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.