4 ms·

Depends on the project, but for a long-running project with a large code base and many contributors (many of whom are no longer actively involved in the project

by neilc 16y ago

Depends on the project, but for a long-running project with a large code base and many contributors (many of whom are no longer actively involved in the project), it can be very valuable. In the case of PostgreSQL, the commit history goes back to ~1995, and most changes are described with a detailed commit message, which can be very helpful when understanding why a certain piece of code behaves the way that it does.

ciupicri 16y ago
But shouldn't the comments from the source code provide an explanation?
- silentbicycle 16y ago
  Commit messages are a better place than comments for explaining the rationale behind cross-cutting changes.
  - nettdata 16y ago
    And knowing what files were touched for the various commits is a big advantage as well.
  - ciupicri 16y ago
    I admit that I've been in situations where I had to find out in what change a piece of code was committed, but on the other hand the code and the comments weren't too great. Also one of the purposes was to find out the author, so that I could pass the bug to him. I'm curious in what situations would a commit message be more appropriate than a comment. A couple of examples would be great. By the way, is there something like Perforce's Time-lapse View tool[1] for git? [1] http://www.perforce.com/perforce/press/pr55.html http://www.perforce.com/perforce/press/pr55.html
    - silentbicycle 16y ago
      Example: "Gathered & cut this code from files A, B, and C, because Client X changed their mind about situation Y, and now we can drop those special cases." Anything involving moving / deleting a lot of code. Adding comments to explain deleted code in several places really doesn't make sense. I don't know about the viewer, but I'm going to look into this soon. We've used p4 for years and are strongly considering switching to git, and if so, I will be doing a lot of helping/explaining during the transition. I really dislike p4 as a VCS (though it was probably the best choice at the time), but agree its diff-viewing tool is actually quite good.
      - ciupicri 16y ago
        I agree that you can't put that explanation into a comment and that a changelog would be fine, but the documentation of the project should also describe what's needed and what not. I guess this is one more reason for the built-in wiki from the Fossil SCM.
    - eeperson 16y ago
      Git has a limited version of that built-in, 'git gui blame' (this is also integrated with the 'gitk' tool). However, that doesn't let you jump quickly to different places in history. If you need some thing that shows you the file 'blame' and quickly lets you easily jump around in history, I recommend 'qgit'.
      - ciupicri 16y ago
        Thanks for the qgit tip, but it's still no match for Perforce.

by neilc 16y ago

ciupicri 16y ago

But shouldn't the comments from the source code provide an explanation?

silentbicycle 16y ago
Commit messages are a better place than comments for explaining the rationale behind cross-cutting changes.
- nettdata 16y ago
  And knowing what files were touched for the various commits is a big advantage as well.
- ciupicri 16y ago
  I admit that I've been in situations where I had to find out in what change a piece of code was committed, but on the other hand the code and the comments weren't too great. Also one of the purposes was to find out the author, so that I could pass the bug to him. I'm curious in what situations would a commit message be more appropriate than a comment. A couple of examples would be great. By the way, is there something like Perforce's Time-lapse View tool[1] for git? [1] http://www.perforce.com/perforce/press/pr55.html http://www.perforce.com/perforce/press/pr55.html
  - silentbicycle 16y ago
    Example: "Gathered & cut this code from files A, B, and C, because Client X changed their mind about situation Y, and now we can drop those special cases." Anything involving moving / deleting a lot of code. Adding comments to explain deleted code in several places really doesn't make sense. I don't know about the viewer, but I'm going to look into this soon. We've used p4 for years and are strongly considering switching to git, and if so, I will be doing a lot of helping/explaining during the transition. I really dislike p4 as a VCS (though it was probably the best choice at the time), but agree its diff-viewing tool is actually quite good.
    - ciupicri 16y ago
      I agree that you can't put that explanation into a comment and that a changelog would be fine, but the documentation of the project should also describe what's needed and what not. I guess this is one more reason for the built-in wiki from the Fossil SCM.
  - eeperson 16y ago
    Git has a limited version of that built-in, 'git gui blame' (this is also integrated with the 'gitk' tool). However, that doesn't let you jump quickly to different places in history. If you need some thing that shows you the file 'blame' and quickly lets you easily jump around in history, I recommend 'qgit'.
    - ciupicri 16y ago
      Thanks for the qgit tip, but it's still no match for Perforce.