4 ms·

I'm trying to imagine my commits coming alive and doing things to my code. I think you may be taking the "When this commit is merged..." thing a bit far, as com

by hmeh 3y ago

I'm trying to imagine my commits coming alive and doing things to my code. I think you may be taking the "When this commit is merged..." thing a bit far, as commits don't actually do anything. They just are. We don't tend to do ourselves any services by anthropomorphizing aspects of our work. I'm happy to concede that we see things very differently.

avgcorrection 3y ago
It has nothing to do with anthropomorphizing. The Git project uses the style of: Refactor x As in: command (verb: refactor) the code to change in this way. That a person wrote the code is irrelevant.
- hmeh 3y ago
  I was responding to the author of the comment I was responding to, who was anthropomorphizing the commit itself claiming that it did something. I agree that the person who write the code is irrelevant, though I realize that in a different way. I also recognize that it varies from Git/Linux/etc. We do it for usability and other reasons and one only needs to look at git itself to recognize that the original authors did not have usability in mind when designing it. What they built is incredibly powerful, but it's rare for usability and technical prowess to overlap.
  - avgcorrection 3y ago
    > I was responding to the author of the comment I was responding to, who was anthropomorphizing the commit itself claiming that it did something. Uh huh. The comment that you replied to is pretty much in line with the wider “patch does X to the code” which isn’t about anthropomorphizing. That’s the spin that you put on it. It’s about as much anthrop. as saying that a falling piano crushed someone’s leg. > We do it for usability and other reasons and one only needs to look at git itself to recognize that the original authors did not have usability in mind when designing it. What they built is incredibly powerful, but it's rare for usability and technical prowess to overlap. It’s also rare to find commit message quality that is on the level of the regular contributors to that project. Which has nothing to do with how unfortunate the UX of the tool is.
    - hmeh 3y ago
      Again, I was responding to this particular text: "And the work does an action on the code." You can interpret that the way that you interpret it. I saw it as a part of a wider tendency in the development community and responded to it accordingly. Perhaps it wasn't what was intended. At this point, it's rather a distraction so I'm happy to concede that it is ambiguous and the author was likely attempting to describe the common "When applied, this commit will..." inferred prefix. > It’s also rare to find commit message quality that is on the level of the regular contributors to that project Good stuff, I'll take a look at it. Thanks!
gavinhoward 3y ago
We call them patches for a reason. Those patches change the code. In essence, I think of commits as edges in a graph between nodes, and the nodes are the repo state. So to me, commits are a state transition; this is why they do something to the code, at least to me.

by hmeh 3y ago

avgcorrection 3y ago

It has nothing to do with anthropomorphizing. The Git project uses the style of: Refactor x As in: command (verb: refactor) the code to change in this way. That a person wrote the code is irrelevant.

hmeh 3y ago
I was responding to the author of the comment I was responding to, who was anthropomorphizing the commit itself claiming that it did something. I agree that the person who write the code is irrelevant, though I realize that in a different way. I also recognize that it varies from Git/Linux/etc. We do it for usability and other reasons and one only needs to look at git itself to recognize that the original authors did not have usability in mind when designing it. What they built is incredibly powerful, but it's rare for usability and technical prowess to overlap.
- avgcorrection 3y ago
  > I was responding to the author of the comment I was responding to, who was anthropomorphizing the commit itself claiming that it did something. Uh huh. The comment that you replied to is pretty much in line with the wider “patch does X to the code” which isn’t about anthropomorphizing. That’s the spin that you put on it. It’s about as much anthrop. as saying that a falling piano crushed someone’s leg. > We do it for usability and other reasons and one only needs to look at git itself to recognize that the original authors did not have usability in mind when designing it. What they built is incredibly powerful, but it's rare for usability and technical prowess to overlap. It’s also rare to find commit message quality that is on the level of the regular contributors to that project. Which has nothing to do with how unfortunate the UX of the tool is.
  - hmeh 3y ago
    Again, I was responding to this particular text: "And the work does an action on the code." You can interpret that the way that you interpret it. I saw it as a part of a wider tendency in the development community and responded to it accordingly. Perhaps it wasn't what was intended. At this point, it's rather a distraction so I'm happy to concede that it is ambiguous and the author was likely attempting to describe the common "When applied, this commit will..." inferred prefix. > It’s also rare to find commit message quality that is on the level of the regular contributors to that project Good stuff, I'll take a look at it. Thanks!

gavinhoward 3y ago

We call them patches for a reason. Those patches change the code. In essence, I think of commits as edges in a graph between nodes, and the nodes are the repo state. So to me, commits are a state transition; this is why they do something to the code, at least to me.