> If something is important enough that people will want to know it when working on the code later, it belongs in either a comment or a change description. Whi

> If something is important enough that people will want to know it when working on the code later, it belongs in either a comment or a change description. Which is indeed what I'm arguing for. I think a lot of what gets done in code review should be directly reflected in the source control change comments. So much to the point that I think a good code review system should be not much more than a thin veneer over a commit log. I agree it's probably a distinction of degree where we disagree. I think the goal of a source control system is to encode source changes in all their forms (including reviews/revisions). Whether or not that is for DVCS "uptime", I see pushing things to an exterior code review system, at least to me, seems a failure in your source control system (or your usage of a source control system), because I see it as such a fundamental part of what constitutes "source control". Git's DAG as it exists already provides a lot of tools to give both "shallow visualizations" at a high level and "deep visualizations" into more complicated back-and-forth processes such as code reviews. Rather than solve these "visualization problems" by outsourcing components of it to external systems, I'd rather see that invested into the DVCS itself and/or the tools we use with the DVCS. (To some extent I think the tools are already there for git, they just have the wrong defaults to encourage more general usage of the DAG to communicate than a lot of projects tend to use.)