I’ve been pushing back on some PRs with messy commit history recently, and I’d like to pretend that my colleague wrote this so I could have something to link to.
It runs given test command for each commit between current head and the selected merge base. This makes sure that each commit passes test suite as most CIs by default check only head commits of request.
I don’t have the data either, but I do have the experience. Bad commit messages and dirty history are the bane of my life. The advice in this post is excellent.
I look at it easily more than 10 times a day. I do think you are on the right track as to why a large population of developers don’t take the time to write useful commit messages. They treat think of it as a write only medium. If I used the git command line or the GitHub web UI to navigate history I wouldn’t check the VC history so often.
If people looked more often, perhaps they would care more about their commits.
I have a gutter with commit messages for each line/chunk in my editor for much of the day since it gives me some context about why a line/function looks as it does.
Right, I am totally for writing good commit messages! They should contain a description of the changes and a link to the ticket. That way you get requirement + architecture idea. But I never look at the graph structure.
I use our git history constantly (we have a clean, well-organized one). I work at a Very Large Enterprise, too. Could your experience be related to not working within a space where the history is clean enough to be reliably usable, rather than it being worthless?
I’ve been pushing back on some PRs with messy commit history recently, and I’d like to pretend that my colleague wrote this so I could have something to link to.
He sort of has. :D
For checking if each commit passes tests I use git-test from Spotify.
You can do this with plain git with
git-rebaseand--exec <cmd>.The conceptual basis - yes, but
git-testwill also cache results and will not rerun tests on commits that have been already checked.From reading the README I can’t figure out what exactly it is testing. Can you give a brief rundown please?
It runs given test command for each commit between current head and the selected merge base. This makes sure that each commit passes test suite as most CIs by default check only head commits of request.
Makes sense. Thanks.
Makes sense. Thanks.
I would have mentioned git-revise, especially when it comes to splitting a commit.
I’ve found splitting by hand difficult enough that I wrote my own script. I’ve never used git-revise. Thanks for the suggestion!
Just say no to cleaning up git history people! You don’t look at it enough to pay off.
Unfortunately, I don’t have data to back up this claim. :/
I don’t have the data either, but I do have the experience. Bad commit messages and dirty history are the bane of my life. The advice in this post is excellent.
I look at it easily more than 10 times a day. I do think you are on the right track as to why a large population of developers don’t take the time to write useful commit messages. They treat think of it as a write only medium. If I used the git command line or the GitHub web UI to navigate history I wouldn’t check the VC history so often.
If people looked more often, perhaps they would care more about their commits.
I have a gutter with commit messages for each line/chunk in my editor for much of the day since it gives me some context about why a line/function looks as it does.
Right, I am totally for writing good commit messages! They should contain a description of the changes and a link to the ticket. That way you get requirement + architecture idea. But I never look at the graph structure.
I use our git history constantly (we have a clean, well-organized one). I work at a Very Large Enterprise, too. Could your experience be related to not working within a space where the history is clean enough to be reliably usable, rather than it being worthless?