Strong disagree.
Commits are actions and should place actions first.
If you need to find a specific item, that is what `git log --grep` is for.
Commits are actions and should place actions first.
If you need to find a specific item, that is what `git log --grep` is for.
In essence, I think of commits as edges in a graph between nodes, and the nodes are the repo state.
So to me, commits are a state transition; this is why they do something to the code, at least to me.
Refactor x
I agree that the person who write the code is irrelevant, though I realize that in a different way. I also recognize that it varies from Git/Linux/etc. We do it for usability and other reasons and one only needs to look at git itself to recognize that the original authors did not have usability in mind when designing it. What they built is incredibly powerful, but it's rare for usability and technical prowess to overlap.
Uh huh. The comment that you replied to is pretty much in line with the wider “patch does X to the code” which isn’t about anthropomorphizing. That’s the spin that you put on it.
It’s about as much anthrop. as saying that a falling piano crushed someone’s leg.
> We do it for usability and other reasons and one only needs to look at git itself to recognize that the original authors did not have usability in mind when designing it. What they built is incredibly powerful, but it's rare for usability and technical prowess to overlap.
It’s also rare to find commit message quality that is on the level of the regular contributors to that project. Which has nothing to do with how unfortunate the UX of the tool is.
> It’s also rare to find commit message quality that is on the level of the regular contributors to that project
Good stuff, I'll take a look at it. Thanks!