5 ms·
> Maybe consider putting your energy into a good documentation inside the repository. Commit messages are documentation. If you have a good commit history you
by lucasoshiro 9mo ago
> Maybe consider putting your energy into a good documentation inside the repository.
Commit messages are documentation.
If you have a good commit history you don't need write tons of documents explaining each decision. The history will contain everything that you need, including: when and who changed the code, what was the code change and why the code exists. You have a good interface for retrieving that documentation (git log, perhaps with -S, -G, --grep, -L and some pathspecs) without needing to maintain extra infrastructure for that and without being cluttered over time (it will be mostly hidden unless you actively search that). You also don't need to remember to update the documents, you are forced to do that after each commit.
And that's not a hack, Git was made for that.
- 1718627440 9mo agoA surprisingly large amount of devs, do the work to record data into a VCS (probably because they are told to by colleagues or superiors), but never seem to use them. Then they tell you that generating proper commits isn't all that important. Well, that's because they never actually use the VCS. By my book, only generating commits isn't really using a VCS, that is the information generation part, you also need to do queries on the collected data, otherwise yes it would be quite useless.
- lucasoshiro 9mo agoAgreed. If they don't care about the history, they don't need a vcs. There's no point in keeping a history if the history isn't helpful
- 1718627440 9mo agoI think they somewhat do care about the history, but only as a backup and list of older versions and as bunch of potential merge bases. But they do not care about the history as in the evolution and causality. It really depends on what you see as the history, so it is a manifestation of a somewhat philosophical problem.