History should be at the keystroke-by-keystroke level, which aggregates into small, focused commits, which aggregates into large merges.
In other words, good written records have layers and organizations. A history book will have chapters, sections, sentences, and footnotes. A database might let me organize my corporate history by day and then by division, or flip it around, and organize by division and then by month.
git his one linear history, which means it is navigable in one way, and you need to pick:
I do not agree. Commits in my patch series have no link whatsoever with the chronology of my work. I wouldn't call it "Git history" as long as it is the branch I'm working on. It becomes history once it is merged inside a more persistent branch.
> git his one linear history
> Don't make me pick!
I'm not understanding what you mean... to me it doesn't.
For example you can browse by 'chapters' by adding `--first-parent` to your `git log`. You have commits, which are paragraphs, then you have merges (ie chapters), and you can view from either view, or many others.
History should be at the keystroke-by-keystroke level, which aggregates into small, focused commits, which aggregates into large merges.
In other words, good written records have layers and organizations. A history book will have chapters, sections, sentences, and footnotes. A database might let me organize my corporate history by day and then by division, or flip it around, and organize by division and then by month.
git his one linear history, which means it is navigable in one way, and you need to pick:
- Complete record of what happened;
- Small, cherry-pickable commits;
- Clean list of when features got merged; or
- Something else
Don't make me pick!