4 ms·

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 whol

by aylons 7y ago

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.

deanCommie 7y ago
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.
- yjftsjthsd-h 7y ago
  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:person@foo.bar" or whatever you want, without baking workflow assumptions into the VCS.
  - Jasper_ 7y ago
    Sounds like you want git notes https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes
  - Kwantuum 7y ago
    > That would let you support "reviewer:person@foo.bar" 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.
- rumanator 7y ago
  > 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.
  - int_19h 7y ago
    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.

by aylons 7y ago

deanCommie 7y ago

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.

yjftsjthsd-h 7y ago
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:person@foo.bar" or whatever you want, without baking workflow assumptions into the VCS.
- Jasper_ 7y ago
  Sounds like you want git notes https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes
- Kwantuum 7y ago
  > That would let you support "reviewer:person@foo.bar" 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.
rumanator 7y ago
> 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.
- int_19h 7y ago
  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.