3 ms·

Fair point — the "why" lives in the developer's head and no diff reader can recover it. The bet is that automating the "what" frees up your commit message to c

Fair point — the "why" lives in the developer's head and no diff reader can recover it. The bet is that automating the "what" frees up your commit message to carry the "why" instead. Most messages today are wasted describing what changed because that felt easier to type. The pre-commit nudge you're describing is the better product though.

magicalhippo 7mo ago
> The bet is that automating the "what" frees up your commit message to carry the "why" instead. Right. For my work I'm not sure that bet would pay off. For (a contrived) example, say I see my colleague has changed a calculation from using price_selected_items = num_selected_items * invoice.item_price to price_selected_items = num_selected_items * invoice.total_item_price / invoice.total_items What has changed is pretty obvious. However without further input or context I can't tell why it changed. So I have to ask my colleague which informs me that the item_price field might be zero if it's not available, but the totals are always accurate. Well, if he'd written that in a comment above, or at least in the commit message, I wouldn't have to disturb him and wait for him to respond. That's the sort of issues I struggle with the most by far when it comes to browsing old commit history. Anyway, just my 2 cents, perhaps it's different for others with other types of work.
- mandeepsng 7mo ago
  That example is spot on and I won't pretend the tool solves it — it can see the field name changed, not that item_price can be zero. Honestly it's made me think the more useful thing is a pre-commit prompt: "this change looks non-obvious, add a comment?" rather than a post-push summary. Different problem entirely. Good 2 cents.
  - magicalhippo 7mo ago
    I literally had a similar case just now. In an integration, if a status field contained X it was changed to Y before the status processing code. My change acted on X hence failed due to status being changed to Y up front. Once I find the offending line, I can easily see what happened, but the why is missing. Fortunately in this case it was documented in the ticket, but would have been preferable to be in code. Without the ticket description I would have been lost. So yeah for me and my team, a tool which tries to identify such cases and alert the dev "oy, this change might not be obvious to others and is lacking comments or commit message explanation" would be much more valuable I think. Perhaps a more difficult task, though I've been surprised by how good these models are these days.
    - mandeepsng 7mo ago
      [dead]
    - mandeepsng 7mo ago
      [dead]

magicalhippo 7mo ago

> The bet is that automating the "what" frees up your commit message to carry the "why" instead. Right. For my work I'm not sure that bet would pay off. For (a contrived) example, say I see my colleague has changed a calculation from using price_selected_items = num_selected_items * invoice.item_price to price_selected_items = num_selected_items * invoice.total_item_price / invoice.total_items What has changed is pretty obvious. However without further input or context I can't tell why it changed. So I have to ask my colleague which informs me that the item_price field might be zero if it's not available, but the totals are always accurate. Well, if he'd written that in a comment above, or at least in the commit message, I wouldn't have to disturb him and wait for him to respond. That's the sort of issues I struggle with the most by far when it comes to browsing old commit history. Anyway, just my 2 cents, perhaps it's different for others with other types of work.

mandeepsng 7mo ago
That example is spot on and I won't pretend the tool solves it — it can see the field name changed, not that item_price can be zero. Honestly it's made me think the more useful thing is a pre-commit prompt: "this change looks non-obvious, add a comment?" rather than a post-push summary. Different problem entirely. Good 2 cents.
- magicalhippo 7mo ago
  I literally had a similar case just now. In an integration, if a status field contained X it was changed to Y before the status processing code. My change acted on X hence failed due to status being changed to Y up front. Once I find the offending line, I can easily see what happened, but the why is missing. Fortunately in this case it was documented in the ticket, but would have been preferable to be in code. Without the ticket description I would have been lost. So yeah for me and my team, a tool which tries to identify such cases and alert the dev "oy, this change might not be obvious to others and is lacking comments or commit message explanation" would be much more valuable I think. Perhaps a more difficult task, though I've been surprised by how good these models are these days.
  - mandeepsng 7mo ago
    [dead]
  - mandeepsng 7mo ago
    [dead]