[Touche]

> Because I've yet to find a git graphlog tool which made viewing pretty nonlinear git history (as precise a historical record as they are) anything but a pain in the ass, some of them barely even manage to display a dozen concurrent "branches".

I'm not following this at all... what is it you need from this tool and why?

> Does it matter that you had to implement 12 fixups at various points and rewrite the whole feature thrice after requirements changed? Probably not.

Yes, code review is an invaluable part of the git history. It explains why you made the decisions you made. And having many small commits rather than 1 massive one makes it much easier to revert bad commits.

[HolyHaddock]

> Yes, code review is an invaluable part of the git history. It explains why you made the decisions you made.

This is interesting - even places I've worked that have cared about commit messages have been pretty happy with the entirely content-free "Fixes from code review."

Do you summarise code review discussions in the commit messages?

[Touche]

Yes, I do, I try to treat each commit like something that can be read in isolation. But nevertheless, the merge commit will have (if using GitHub) a reference to the pull request where you can see the discussion, which is valuable imo.

[HolyHaddock]

Have you had any feedback from colleagues that have found that useful?