Re:Rob Pike on good commit messages (2014)
by kspacewalk2 on Thursday December 19, 2019 @05:13PM
(#21839841)
Git tools may be routed in email, but they most certainly aren't used that way by most people. Why would I write a commit message like I'm writing an email if both the commit message and email are the wrong tools for the job? We have issues are PRs for code discussion within the context of code. This priceless information should live with the repo. Not in some isolated silo like email which is not accessible to people who aren't on the chain, or commit messages that are difficult and time consuming to traverse in any but the simplest and smallest repos.
Re:Rob Pike on good commit messages (2014)
by zenhack on Thursday December 19, 2019 @06:36PM
(#21840397)
Fossil[1] integrates a bug tracker & wiki into the repo proper, and I agree that it would be good for these to just stay pinned together in general. I'm kinda sad that git has basically "won" the SCM wars in the FOSS world; a decade ago there was a lot of interesting experimentation happening and I feel like having a winner has caused that to stagnate.
Re: Email being an inaccessible silo: communities that use git-format-patch/git-am usually use mailing lists, which are archived, and subject lines have [PATCH] in them so searching needn't be difficult.
There is always a reason why things are 1) done and 2) done in this specific way and not another. It is also relevant if this is part of a larger change and it there are external dependencies on this commit. These things must be clear from the commit message.
> you're just doing janitor work
That makes it sound like janitorial work does not require complete commit messages which is why we sometimes see useless messages. There is always a reason why something was done and this can be documented.
A bug can be documented why it happened, why it was fixed in this specific way and not some other more obvious way, and what steps has been taken not avoid it from resurfacing. The same way a clean up can describe why others paths were not taken, why the new way is considered more clean (fewer lines, lesser complexity?) and how we know it does not entail functional changes.
The git tool is rooted in email, and commit messages look a lot like it. Pretend you are describing your patch over email to someone and it will be almost trivial to write.