3 ms·

It's great for historical research though. It's one of the few pieces of documentation that will live with the code forever. github and other forms of centraliz

It's great for historical research though. It's one of the few pieces of documentation that will live with the code forever. github and other forms of centralization are not open data formats that folks trivially backup/convert/carry forward. They usually leave the data behind if they move the project somewhere else. So no, I don't think it helps the current community much either. But it helps the debugger years later.

schacon 3y ago
Is it great for historical research? I feel like the format and tooling around it is uniquely _not great_ for historical research. I think it's optimized for discussions before integration, which is largely what PR descriptions and comments are largely used for now. I feel like given great commit messages, determining a story and useful history around any block of code given the Git tooling is incredibly difficult even if there are _amazing_ commit messages. Like say you are trying to determine why a 10 line function is the way that it is. You blame it. Not even with the stupid-simple GitHub UI that _I_ originally wrote, but with the more expensive CLI interface that follows renames and ignores whitespace changes, etc. Now you get a list of SHAs of commits and the first 50 chars of commit messages for each line for the last modifications, etc. How do you even stitch those messages into a useful story (in order) to tell you how that function evolved to what it is now and why?
- cesarb 3y ago
  It might depend on which tools you're using. When I'm doing historical research for how a function evolved, I normally run "gitk" on the file, and walk through the commits; the full commit message is shown together with each diff to the file. It used to be even better in the past, when gitk showed the full commit diff, instead of the diff to just the file I passed on the command line, but "git show" on the commit hash (or another gitk which is not filtered to a path) is good enough.
- deleted 3y ago
  [deleted]
- lazyasciiart 3y ago
  P4V (Perforce Visual Client) is amazing for visual historical research. I haven't seen a git tool like it, but I'd love one. https://www.perforce.com/video-tutorials/vcs/using-time-lapse-view https://www.perforce.com/video-tutorials/vcs/using-time-laps...
- somerandomqaguy 3y ago
  Tediously commit by commit. But it's often better then the alternative. Design decisions and business logic separately from the code or source control are infinitely harder to reference code against, and realistically that documentation will be lost. At least if you have the git repo then there's at least some chance to be able to git through the history of some code that's kept with the code. Especially for stuff that code cannot document and you're working with devs that seem to be firmly believe that code is self documenting. Doesn't mean that every code base needs to have amazing git commits. But code bases expected to live a long time at least give some possibility to string together a history after some work.
- keybored 3y ago
  > I think it's optimized for discussions before integration, which is largely what PR descriptions and comments are largely used for now. As a GitHub co-founder, whose fault is that? I have seen many great PR descriptions on GitHub that never make their way into the final inclusion in the main/master git history. Meanwhile the git project links every commit to the message id whence the original patch (for many years now—not the whole history). Which will be available as long as the email archives are out there somewhere. And the commit messages get reviewed into a good shape. Something that I’ve never seen anyone do on GitHub.
  - neilkk 3y ago
    But Github and similar tools actually solved this problem where Git failed to do so. Nowadays people have a setup with Github or bitbucket where they can navigate from a piece of code right to the pull request, where they can read the code review discussion, see the build log, reach linked resources like the Jira, etc.
    - keybored 3y ago
      “Just go to our web app” is not solving the same problem as what Git is trying to solve (the latter sometimes badly, it might be added).
- mtrower 3y ago
  > I think it's optimized for discussions before integration, which is largely what PR descriptions and comments are largely used for now. This isn't even a git concept though; it's something that was tacked on top of it. What you seem to be saying here is that a third-party tool building on top of git spawned a social movement that moved this layer up a level. Not every project uses github or a github workflow. > I think it's optimized for discussions before integration It's optimized for discussion of the purpose of the code unit in question. That discussion can be useful before integration; but pre-integration discussion can happen any way you like. PR discussions work, e-mails on mailing lists work. Face-to-face discussion works. The real value (for me, I guess; apparently you just don't see it that way) is explaining the purpose (and possibly circumstances) of the commit, after the fact, when I'm looking at it for some reason or other. Not finding the commit, but explaining it once I'm there. A well-written commit message can be absolutely priceless. Maybe this last point should go in a top-level response to your original comment, but I'm already here, so I'll just say it here. Saying that commit messages are terrible because only short-messages (the "subject line") are shown by default, seems to me about the same as saying e-mail bodies are useless for the same reason, or that file contents are terrible because `find` only lists file names by default. You 'have' to collapse by default, or you'd drown in a sea of commit messages anytime you tried to list anything. > Like say you are trying to determine why a 10 line function is the way that it is. You blame it. Not even with the stupid-simple GitHub UI that _I_ originally wrote, but with the more expensive CLI interface that follows renames and ignores whitespace changes, etc. Now you get a list of SHAs of commits and the first 50 chars of commit messages for each line for the last modifications, etc. How do you even stitch those messages into a useful story (in order) to tell you how that function evolved to what it is now and why? Okay, I hear you, this is not the most ergonomic procedure to one-off. But seriously, you have the SHA commits. If you need to do this often, write a tool that takes those SHA commits, orders them based on log order (or chronological order, w/e, pick an ordering mechanism), and prints out whatever information is interesting to you. A simple display that can expand/collapse full messages, diffs, etc. would probably do nicely. It can be a GUI tool, a CLI tool (menu-driven, maybe); whatever works for you. This should not be a big deal to write for the common case, and if you think it's that critical to the community, publish it.
- atq2119 3y ago
  I feel like you're complaining about a problem which you helped create. So, with all due respect, do your part to fix it. For example, by allowing review comments on commit messages in GitHub. Gerrit gets this right, FWIW.
lanstin 3y ago
Till the team you are handing off the code to just copies the files and commits into a fresh new repo without any of the history. I had this happen once to a server I wrote, and then like 2 years later the new team comes and asks me if I knew of the server, and I'm like "I wrote it" and then they are all confused.

schacon 3y ago

Is it great for historical research? I feel like the format and tooling around it is uniquely _not great_ for historical research. I think it's optimized for discussions before integration, which is largely what PR descriptions and comments are largely used for now. I feel like given great commit messages, determining a story and useful history around any block of code given the Git tooling is incredibly difficult even if there are _amazing_ commit messages. Like say you are trying to determine why a 10 line function is the way that it is. You blame it. Not even with the stupid-simple GitHub UI that _I_ originally wrote, but with the more expensive CLI interface that follows renames and ignores whitespace changes, etc. Now you get a list of SHAs of commits and the first 50 chars of commit messages for each line for the last modifications, etc. How do you even stitch those messages into a useful story (in order) to tell you how that function evolved to what it is now and why?

cesarb 3y ago
It might depend on which tools you're using. When I'm doing historical research for how a function evolved, I normally run "gitk" on the file, and walk through the commits; the full commit message is shown together with each diff to the file. It used to be even better in the past, when gitk showed the full commit diff, instead of the diff to just the file I passed on the command line, but "git show" on the commit hash (or another gitk which is not filtered to a path) is good enough.
deleted 3y ago
[deleted]
lazyasciiart 3y ago
P4V (Perforce Visual Client) is amazing for visual historical research. I haven't seen a git tool like it, but I'd love one. https://www.perforce.com/video-tutorials/vcs/using-time-lapse-view https://www.perforce.com/video-tutorials/vcs/using-time-laps...
somerandomqaguy 3y ago
Tediously commit by commit. But it's often better then the alternative. Design decisions and business logic separately from the code or source control are infinitely harder to reference code against, and realistically that documentation will be lost. At least if you have the git repo then there's at least some chance to be able to git through the history of some code that's kept with the code. Especially for stuff that code cannot document and you're working with devs that seem to be firmly believe that code is self documenting. Doesn't mean that every code base needs to have amazing git commits. But code bases expected to live a long time at least give some possibility to string together a history after some work.
keybored 3y ago
> I think it's optimized for discussions before integration, which is largely what PR descriptions and comments are largely used for now. As a GitHub co-founder, whose fault is that? I have seen many great PR descriptions on GitHub that never make their way into the final inclusion in the main/master git history. Meanwhile the git project links every commit to the message id whence the original patch (for many years now—not the whole history). Which will be available as long as the email archives are out there somewhere. And the commit messages get reviewed into a good shape. Something that I’ve never seen anyone do on GitHub.
- neilkk 3y ago
  But Github and similar tools actually solved this problem where Git failed to do so. Nowadays people have a setup with Github or bitbucket where they can navigate from a piece of code right to the pull request, where they can read the code review discussion, see the build log, reach linked resources like the Jira, etc.
  - keybored 3y ago
    “Just go to our web app” is not solving the same problem as what Git is trying to solve (the latter sometimes badly, it might be added).
mtrower 3y ago
> I think it's optimized for discussions before integration, which is largely what PR descriptions and comments are largely used for now. This isn't even a git concept though; it's something that was tacked on top of it. What you seem to be saying here is that a third-party tool building on top of git spawned a social movement that moved this layer up a level. Not every project uses github or a github workflow. > I think it's optimized for discussions before integration It's optimized for discussion of the purpose of the code unit in question. That discussion can be useful before integration; but pre-integration discussion can happen any way you like. PR discussions work, e-mails on mailing lists work. Face-to-face discussion works. The real value (for me, I guess; apparently you just don't see it that way) is explaining the purpose (and possibly circumstances) of the commit, after the fact, when I'm looking at it for some reason or other. Not finding the commit, but explaining it once I'm there. A well-written commit message can be absolutely priceless. Maybe this last point should go in a top-level response to your original comment, but I'm already here, so I'll just say it here. Saying that commit messages are terrible because only short-messages (the "subject line") are shown by default, seems to me about the same as saying e-mail bodies are useless for the same reason, or that file contents are terrible because `find` only lists file names by default. You 'have' to collapse by default, or you'd drown in a sea of commit messages anytime you tried to list anything. > Like say you are trying to determine why a 10 line function is the way that it is. You blame it. Not even with the stupid-simple GitHub UI that _I_ originally wrote, but with the more expensive CLI interface that follows renames and ignores whitespace changes, etc. Now you get a list of SHAs of commits and the first 50 chars of commit messages for each line for the last modifications, etc. How do you even stitch those messages into a useful story (in order) to tell you how that function evolved to what it is now and why? Okay, I hear you, this is not the most ergonomic procedure to one-off. But seriously, you have the SHA commits. If you need to do this often, write a tool that takes those SHA commits, orders them based on log order (or chronological order, w/e, pick an ordering mechanism), and prints out whatever information is interesting to you. A simple display that can expand/collapse full messages, diffs, etc. would probably do nicely. It can be a GUI tool, a CLI tool (menu-driven, maybe); whatever works for you. This should not be a big deal to write for the common case, and if you think it's that critical to the community, publish it.
atq2119 3y ago
I feel like you're complaining about a problem which you helped create. So, with all due respect, do your part to fix it. For example, by allowing review comments on commit messages in GitHub. Gerrit gets this right, FWIW.

lanstin 3y ago

Till the team you are handing off the code to just copies the files and commits into a fresh new repo without any of the history. I had this happen once to a server I wrote, and then like 2 years later the new team comes and asks me if I knew of the server, and I'm like "I wrote it" and then they are all confused.