| I'm not sold on the idea of the master log as a readable narrative. If you really want to maintain such a narrative, it would be possible to do it separately, in something like a changelog. You might even hire someone to do that, a kind of technical historian. It's real work, because software development is pretty messy. If you reaaally care about the history of the software's development, I would seriously consider aggressive rebasing of the repository even much later -- you could refactor the commit history as much as you want to clarify the logical progression of the software. As I see it, a source code repository is not like a history book, because a history book is written after the fact by a trained historian who spends a lot of energy on tidying up the narrative and making it actually comprehensible. A source code repository looks to me more like an archaelogical artifact with some terse notes sprinkled in there as clues by the various workers. Basically I think the git log structure is kind of overblown and workflow arguments that hinge on the legibility of the repository's graph structure don't really matter that much to me. I still sometimes write pretty involved commit messages, but that's a kind of separate issue from these "workflow" discussions that are mostly about how you should formally arrange the DAG. And I also know that my commit messages are mostly lost in time like tears in rain, so I try to communicate important changes in other ways. |