4 ms·

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 his

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.
  - afiori 7y ago
    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.
  - jerf 7y ago
    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.)
- cousin_it 7y ago
  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".
  - philwelch 7y ago
    By that logic we'd all be using Lotus Notes.
breck 7y ago
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?

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.
- afiori 7y ago
  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.
- jerf 7y ago
  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.)
cousin_it 7y ago
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".
- philwelch 7y ago
  By that logic we'd all be using Lotus Notes.

breck 7y ago

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?