I don't think this should be part of version control, simply because is too tied to the environment and development practices that may not be shared by the whole set of current and future developers of any given project.

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.

I think the distinction you're drawing between code history and paperwork history is more arbitrary than you give it credit.

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 think the distinction you're drawing between code history and paperwork history is more arbitrary than you give it credit.

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.

If you can annotate an entire commit with a message, why not allow annotating parts of a commit (file/span) with a message, and why not allow those messages to form threads?

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.

I agree that such feature would be valuable, but I also have a counterpoint to answer the 'why not'

A difference between a commit message and a code comment/thread is that a commit message is more authoritative.

You could actually do that today with the Git model if you want to, so, arguably, the question is, why doesn't your code review tool already put its history in git?

(Probably some combination of nobody asking for it, and in some cases, wanting to keep your code review process locked in to the tool.)

I kind of agree with grandparent, though. When the IDE, source control, code review and task tracking work together seamlessly, it's glorious. If your software says "it's not my job", it will be outcompeted by software that says "heck yeah it's my job".

By that logic we'd all be using Lotus Notes.

I would like a workflow with all of the features of GitHub (code reviews, issue tracking, etc), but everything stored in Git.

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?

Perhaps commits should support key:value metadata? (I was about to say "tags", but that means something different here) That would let you support "reviewer:[email protected]" or whatever you want, without baking workflow assumptions into the VCS.

Sounds like you want git notes

https://git-scm.com/docs/git-notes

> That would let you support "reviewer:[email protected]"

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.

I disagree. Git handles this through the power to push/pull and muddying that with a bunch of alternative baked in user flows seems like a mistake. Third party software can handle adding meta-information to pull requests.

> And yes, there are external tools for code review. But that all should be a part of version control.

There are many different code-review workflows, and for teams that do full-time pair-programming, code review happens in real-time as the code is written.

Trying to bake support for all of that into something that is also a good VCS sounds like a recipe for one of those clock-birdfeeder-machete-flashlight-massager tools that you used to see on the back pages of outdoor magazines in the 90s.

e.g. -- fossil.

This is exactly the issue with it: its author(s) lament that git has not all of these things integrated, but they are ignoring that this is exactly why fossil cannot gain a wider adoption.

It has opinions about how the team and the project should be run / managed / documented. This is not for the tool dev to have these opinions

Iron [1] definitely has the right idea.

Code review comments really should live next to the code, and proper editor integration goes a really long way. Traditional review processes make “just fixing the code” have a very high inertia.

[1] https://blog.janestreet.com/ironing-out-your-release-process...

Thanks for this one, really nice read.

I think it doesn't exist because there is no demand for that to be part of the codes history. Nothing you've described sounds very useful after a month or so.

All this talk of Git-sympathetic code review tools and nobody has mentioned Gerrit, which seems at least somewhat close to what is being described. Each patchset of each review is its own Git ref and is often referenced in the final commit.

Separately, I know many including myself who would love for code review comments to more seamlessly be integrated into the code browsing experience.

People also seem to be conflating review comments associated with lines of code with an opinionated code review tool.

You can keep the banter with the code and the go-no-go decision separate, even external. But post mootems have worked better when someone realized that one of the team repeatedly calls out a class of errors that bite us later and they’re being ignored. You have the ability to prevent this error. Wise up or that person will decide rightfully that we are a bunch of clowns and leave.

Sure, but keeping that history is just a small part of what I said.

The point about code review still stands.

That's the one major point where Fossil probably falls short: Extending a repository's capabilities would add overhead to every single one of them (and, potentially, to each commit's meta data).

Something like https://github.com/google/git-appraise ?

> "There is no code review in Git."

Yes there is. You can block pushing directly to a branch of the repository and demand that things can only be merged through pull requests. You code review the pull requests.

This is very well supported by Atlassian's git tooling, for example. It does everything you mention. It's true that the comments don't become part of the git repository itself, but I'm not convinced they should be.

Sounds like the Google workflow.