5 ms·

It seems pretty safe to assume a developer contributing C code to git itself would know how to use git blame (or the GitHub interface for it).

by grncdr 6y ago

orf 6y ago
Why make it harder, and why make it impossible to update if there are other suggested alternatives that are available since whenever the commit was made?
- masklinn 6y ago
  > Why make it harder Because there is no way for a commit message to become outdated or detached from what it talks about, both of which are very much issues with comments. > why make it impossible to update if there are other suggested alternatives that are available since whenever the commit was made? Because that doesn't really matter.
  - orf 6y ago
    > Because that doesn't really matter. Ok, so maybe rather than have this file we should run “git log | grep BANNED” and build a list of functions from that? Or maybe we could change all error messages to be “go look at the commit history to work out why this happened”. No? Maybe putting context in source files (or better yet, an error message!) rather than in a side channel like the commit message has value when it comes to understanding and updating, and it won’t be lost under the weight of future commits.
    - deleted 6y ago
      [deleted]
    - capableweb 6y ago
      Your source code should describe what the program should do today. It should not contain all historical artifacts about your source code, as it'll grow to big and unmanageable then. Instead, use Git to store temporal information, data that is about change and reasoning behind it. Git is basically a timeline, instead of hard facts of today. That's why it makes sense to describe the background and reasoning behind a change in a Git commit, instead of inside your source files as comments.
      - orf 6y ago
        Totally agree, which is why nobody is suggesting adding the background and reasoning behind the change to the source file as a comment. They are suggesting adding a more informative error, which may include a subset of that background and reasoning. An error message that points you to the functions you should use instead is infinitely more informative than one that says “this is banned. Bye.”
        jorl17 6y ago
        Precisely.
  - underwater 6y ago
    Code is evergreen, whereas a git commit represents a change at a single point in time. It will always be limited by the knowledge the author had available to them. The commit message from 2020 with suggested alternatives might very well go stale. Does the author go and force a noop commit so they can document new best practice in a new commit message?
  - cma 6y ago
    > Because there is no way for a commit message to become outdated or detached from what it talks about, both of which are very much issues with comments. What if they think of another reason why one of the same functions should be disabled?
jorl17 6y ago
I find it highly backwards that documentation on "what to use instead of X" is in the commit message disabling X. One _might_ do it and might remember to do it, but IMO it makes absolutely no sense for this not to be documented properly in code, as suggested by OP. By that logic, a non-insignificant amount of (good) comments in code could be removed and people asked to "git blame the code and check out the commit that made it for the documentation". Of course this could be done, but it sounds ridiculous even typing it out.
- capableweb 6y ago
  > By that logic, a non-insignificant amount of (good) comments in code could be removed and people asked to "git blame the code and check out the commit that made it for the documentation". Of course this could be done, but it sounds ridiculous even typing it out. Yes, exactly. You want to understand how a codebase changed and evolved over time? Git is your friend. If you want the facts of the code today? The source code is your friend. That's why the way Linux and Gits Git repository method of storing history makes sense. See also https://news.ycombinator.com/item?id=26348965 https://news.ycombinator.com/item?id=26348965 Try navigating the Git codebase with a git-blame sidebar (probably VS Code has that somewhere) so you can see the history of the source files. If you wonder why something is what it is, you can checkout the commit that last modified it. Or go even further backwards and figure out in the context it was first added. If you truly want to understand a change, a git repository with well written git messages is a pleasure to understand and dig into.
  - jorl17 6y ago
    > Yes, exactly. You want to understand how a codebase changed and evolved over time? Git is your friend. If you want the facts of the code today? The source code is your friend. 100% agree. Though I don't mind if comments also leave historical information about the code. Can't be too much -- there is a delicate balance. Do note, however, that you said it yourself: If you want the facts of the code today, go to the source code. In my opinion, the "facts of the code of git" are that functions X,Y,Z are "banned", but the code does not tell me why, or what to use instead. It just bans them. I would expect to see something in the code, not (just) in a git commit. It's also not that I can't google these functions (a couple of minutes will answer these questions), or that I should be experienced enough to know why they're evil, it's that it's IMO a reasonable, developer-friendly and good thing to do.

It seems pretty safe to assume a developer contributing C code to git itself would know how to use git blame (or the GitHub interface for it).

by grncdr 6y ago

It seems pretty safe to assume a developer contributing C code to git itself would know how to use git blame (or the GitHub interface for it).

orf 6y ago

Why make it harder, and why make it impossible to update if there are other suggested alternatives that are available since whenever the commit was made?

masklinn 6y ago
> Why make it harder Because there is no way for a commit message to become outdated or detached from what it talks about, both of which are very much issues with comments. > why make it impossible to update if there are other suggested alternatives that are available since whenever the commit was made? Because that doesn't really matter.
- orf 6y ago
  > Because that doesn't really matter. Ok, so maybe rather than have this file we should run “git log | grep BANNED” and build a list of functions from that? Or maybe we could change all error messages to be “go look at the commit history to work out why this happened”. No? Maybe putting context in source files (or better yet, an error message!) rather than in a side channel like the commit message has value when it comes to understanding and updating, and it won’t be lost under the weight of future commits.
  - deleted 6y ago
    [deleted]
  - capableweb 6y ago
    Your source code should describe what the program should do today. It should not contain all historical artifacts about your source code, as it'll grow to big and unmanageable then. Instead, use Git to store temporal information, data that is about change and reasoning behind it. Git is basically a timeline, instead of hard facts of today. That's why it makes sense to describe the background and reasoning behind a change in a Git commit, instead of inside your source files as comments.
    - orf 6y ago
      Totally agree, which is why nobody is suggesting adding the background and reasoning behind the change to the source file as a comment. They are suggesting adding a more informative error, which may include a subset of that background and reasoning. An error message that points you to the functions you should use instead is infinitely more informative than one that says “this is banned. Bye.”
      - jorl17 6y ago
        Precisely.
- underwater 6y ago
  Code is evergreen, whereas a git commit represents a change at a single point in time. It will always be limited by the knowledge the author had available to them. The commit message from 2020 with suggested alternatives might very well go stale. Does the author go and force a noop commit so they can document new best practice in a new commit message?
- cma 6y ago
  > Because there is no way for a commit message to become outdated or detached from what it talks about, both of which are very much issues with comments. What if they think of another reason why one of the same functions should be disabled?

jorl17 6y ago

I find it highly backwards that documentation on "what to use instead of X" is in the commit message disabling X. One _might_ do it and might remember to do it, but IMO it makes absolutely no sense for this not to be documented properly in code, as suggested by OP. By that logic, a non-insignificant amount of (good) comments in code could be removed and people asked to "git blame the code and check out the commit that made it for the documentation". Of course this could be done, but it sounds ridiculous even typing it out.

capableweb 6y ago
> By that logic, a non-insignificant amount of (good) comments in code could be removed and people asked to "git blame the code and check out the commit that made it for the documentation". Of course this could be done, but it sounds ridiculous even typing it out. Yes, exactly. You want to understand how a codebase changed and evolved over time? Git is your friend. If you want the facts of the code today? The source code is your friend. That's why the way Linux and Gits Git repository method of storing history makes sense. See also https://news.ycombinator.com/item?id=26348965 https://news.ycombinator.com/item?id=26348965 Try navigating the Git codebase with a git-blame sidebar (probably VS Code has that somewhere) so you can see the history of the source files. If you wonder why something is what it is, you can checkout the commit that last modified it. Or go even further backwards and figure out in the context it was first added. If you truly want to understand a change, a git repository with well written git messages is a pleasure to understand and dig into.
- jorl17 6y ago
  > Yes, exactly. You want to understand how a codebase changed and evolved over time? Git is your friend. If you want the facts of the code today? The source code is your friend. 100% agree. Though I don't mind if comments also leave historical information about the code. Can't be too much -- there is a delicate balance. Do note, however, that you said it yourself: If you want the facts of the code today, go to the source code. In my opinion, the "facts of the code of git" are that functions X,Y,Z are "banned", but the code does not tell me why, or what to use instead. It just bans them. I would expect to see something in the code, not (just) in a git commit. It's also not that I can't google these functions (a couple of minutes will answer these questions), or that I should be experienced enough to know why they're evil, it's that it's IMO a reasonable, developer-friendly and good thing to do.