If all we cared about was code history, a super pure "version control" system would have one trunk, no branches, and a sequentially increasing version number with no commit messages or author information.
But if you can annotate an entire commit with a descriptive message, why not annotate a specific hunk of code changes (comments), or the discussion over those changes in a specific version?
Environments and development practices may change, but the code review that led to a particular code decision at some point in history are a valid representation of the context at that time in history.
Don't get me wrong, I'm not lacking these features in Git, and am happy to get them from other platforms like Github, but I think the comment you're responding to is astute that one can imagine a git replacement that incorporates code review functionality as a first-tier feature.
I don't agree. The responsibility of a version control system is to manage the changes made to the source code. The paperwork that goes with it is an entirely different, and separate, responsibility, just like ticketing systems and keeping track of tasks, epics, sprints, etc.
> If all we cared about was code history, a super pure "version control" system would have one trunk, no branches, and a sequentially increasing version number with no commit messages or author information.
That doesn't make sense because you're ignoring the fact that branches are used to host versions that are being developed independently at a specific moment in time, and merges are used to finally join contributions when they are ready to be added to the main branch. If you look at single branches and ignore the work being developed in any other branch, the history is as linear as you expected it to be.
> But if you can annotate an entire commit with a descriptive message
But you can.
At which point you get code review that is logged entirely in the history of the repo. Which is a very useful feature, and a huge value proposition of GitHub over raw git - git blame gives you the commit, but GitHub will also gives you the pull request for that commit, and you can go and look at the comments there to understand why it was done the way it was.
A difference between a commit message and a code comment/thread is that a commit message is more authoritative.
(Probably some combination of nobody asking for it, and in some cases, wanting to keep your code review process locked in to the tool.)
Perhaps every project might have a branch called "issues" or "reviews", etc. Not sure the best setup but generally the more I can do in my code editors the faster I can work.
Has anyone found good work patterns like that?
It's very weird to me that you would use reviewer as your example because that's pretty much the exact point of the signoff feature.
The version control should keep the code history, not the paperwork history.
What I think you're looking for could, however, use git as a platform for that. That's what GitHub, GitLab and the likes do using a web interface and there's enough extensibility and power on git for command-line or desktop tools to do it.
The internals of git are very much akin to a filesystem, by the way, and the plumbing gives you more enough access to use that in creative ways.
From the top of my head, maybe a system like this could automatically generate tags for code reviews, use merges and branching for answering to these reviews, and hooks for notifying interested parts on particular areas of code. All while the messages and reviews themselves travel on another data layer, which references git but does not mingle with it.
This separation (and even tag cleaning, for example), would be specially useful on huge distributed projects where a company or small team may have whatever development process it needs internally and sharing only the results without having to completely hide the code history.