The commit message idea always felt a little strange/off to me. It's a string that you can't (generally) fix/extend later for those who may seek this informatio

The commit message idea always felt a little strange/off to me. It's a string that you can't (generally) fix/extend later for those who may seek this information. Also nobody except the committer can write them. (Imagine an explicit @docsguy role for documenting commits along with writing ticket-based documentation.) What if VCSs used a single file or a folder, like .gitcommits, where anyone could append any sort of info in the same commit, so it could be a part of it. Then, when you commit a feature, you add to this file(-s): @@ @@ +--- +added websocket support to the server + /ws - main socket + /ws-events - events socket And few commits later you decide to extend it, editing the same record: @@ @@ +--- +added json-rpc over websockets + /ws-json-rpc And VCS would then extract these records at `git log`: ... 4509812 added websocket support to the server 0732691 <no .gitcommits message> 8712389 added json-rpc over websockets Few commits later @docsguy expand on json-rpc: @@ @@ --- -added json-rpc over websockets +added lifetime-related json-rpc over websockets +task: ./tasks/1873.md +supports 'start' and 'stop' methods: ./doc/ws-lifetime.md /ws-json-rpc @@ @@ +--- +enhanced commit descriptions A tasks/1873.md A doc/ws-lifetime.md 4509812 added websocket support to the server 0732691 <no .gitcommits message> 8712389 added lifetime-related json-rpc over websockets 6034007 enhanced commit descriptions Full commit messages would then be just diffs. Also, one could write a commit message gradually, with the sources they are modifying. Or write two commit messages at once (because we all do commit two+ changes sometimes): @@ @@ +--- +refactored foo bar heavily, @docsguy please expand +--- +fixed a bug in baz, didn't care to backport ... 0923423 refactored foo bar heavily, @docsguy please expand fixed a bug in baz, didn't care to backport