3 ms·

I agree with the principal, but in practice the mailing list post is pretty inscrutable to me (as a casual git user, maybe more experienced users find it more h

by remus 5y ago

I agree with the principal, but in practice the mailing list post is pretty inscrutable to me (as a casual git user, maybe more experienced users find it more helpful?) On the other hand the github blog post provides a lot of extra context and explanation around the changes which adds a lot of value to me.

chucky 5y ago
I agree, I think changing the title is a better solution than linking to the release notes, but I still think it makes sense to offer extra clarity. The original title of the blog post is "Highlights from Git 2.33" which to me is a bit clearer that this is not release notes or any kind of "official" Git 2.33 announcement but rather someone's highlights about Git 2.33. I have no idea why the original submitter chose to edit the title like this.
- usr1106 5y ago
  > I have no idea why the original submitter chose to edit the title like that Not only that; editing the title is against HN submission guidelines. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
capableweb 5y ago
I also agree in principal and agree that the GitHub post with additional context is nice. But I'm wondering if this is rather feedback for the Git team to do better release notes (like the GitHub team here) as GitHub will always be biased with their release notes, so it would be better for everyone is the release note from Git were as well. In this particular release, `send-email` is mentioned in the top in the mailing list as it has a new feature. However, GitHub have zero interest in people to use `send-email` as they are basically a competitor to the `send-email` command. So they simply don't mention it in their release notes. This is of course bad, and I'm not sure why they wouldn't at least try to remain impartial. But this is why we need the release notes of the Git team to be better.
alimbada 5y ago
Noisy text file littered with mail header, lists of names, commit hashes and branch names, file names, commit messages and the only emphasised aspect being hyperlinks which stick out like a sore thumb vs. a well formatted blog post with clear headings, easy to read font, diagrams for architectural changes, code examples and even an animated GIF. Yeah, I know which one I'm choosing (the latter).

by remus 5y ago

chucky 5y ago

I agree, I think changing the title is a better solution than linking to the release notes, but I still think it makes sense to offer extra clarity. The original title of the blog post is "Highlights from Git 2.33" which to me is a bit clearer that this is not release notes or any kind of "official" Git 2.33 announcement but rather someone's highlights about Git 2.33. I have no idea why the original submitter chose to edit the title like this.

usr1106 5y ago
> I have no idea why the original submitter chose to edit the title like that Not only that; editing the title is against HN submission guidelines. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

capableweb 5y ago

I also agree in principal and agree that the GitHub post with additional context is nice. But I'm wondering if this is rather feedback for the Git team to do better release notes (like the GitHub team here) as GitHub will always be biased with their release notes, so it would be better for everyone is the release note from Git were as well. In this particular release, `send-email` is mentioned in the top in the mailing list as it has a new feature. However, GitHub have zero interest in people to use `send-email` as they are basically a competitor to the `send-email` command. So they simply don't mention it in their release notes. This is of course bad, and I'm not sure why they wouldn't at least try to remain impartial. But this is why we need the release notes of the Git team to be better.

alimbada 5y ago

Noisy text file littered with mail header, lists of names, commit hashes and branch names, file names, commit messages and the only emphasised aspect being hyperlinks which stick out like a sore thumb vs. a well formatted blog post with clear headings, easy to read font, diagrams for architectural changes, code examples and even an animated GIF. Yeah, I know which one I'm choosing (the latter).