Hm, thanks. I would love to be able to address the potential usefulness concern in the ticket, but unfortunately I don’t seem to be able to get an account set up, so I’ll write it here:
I don’t know what Phabricator’s mission is, but if it was my company, part of it would be to enable and promote good coding practices. Most projects start out without code review processes in place, on the theory that it would slow down development too much. The problem is, they stay that way. Not being able to efficiently get an existing codebase into “completely reviewed” state is a huge barrier to entry for such projects, which as I claim is most of them. Further, I can guarantee that I would have taken several large projects through the process to get into that state if the tool was available. The fact that some “large ideas that span commits and files” could be overlooked in such a process doesn’t in any way negate the value of doing it. It’s much more likely that they will be caught if it is done than if it is not done.
Finally, this is not only of value to whole codebases. It is also very common that individual source files, documents, and proposals under development undergo many revisions before someone with useful feedback gets to review them. What’s important at that point is not how the state was arrived at, but that it makes sense as a whole. It’s also very common that I’m looking at the latest revision of a source file and I notice one or more things that look wrong that I want to raise as issues. At that point, I want to be able to launch an audit of that file (and maybe a few other related ones). Having to dig through revision history just to figure out where the relevant changes are is prohibitive, and since the changes might be disjoint there’s often no good way to create such a review.
I hope I’ve made the case for whole-file review in a useful (and convincing!) way. Thanks for listening.