5 ms·

I think this should link directly to Git's release notes (e.g. https://lore.kernel.org/git/xmqq1r6touqi.fsf@gitster.g/ https://lore.kernel.org/git/xmqq1r6touqi.

by chucky 5y ago

I think this should link directly to Git's release notes (e.g. https://lore.kernel.org/git/xmqq1r6touqi.fsf@gitster.g/ https://lore.kernel.org/git/xmqq1r6touqi.fsf@gitster.g/), or the title should be updated to somehow reflect that this is Github's blog post about the changes, not Git's official announcement. Git is not owned or stewarded by Github, and posts like this reinforce the common and unfortunate image that it is.

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).
throwawayswede 5y ago
Not to mention that the actual Git release note includes the names of new and returning contributors, which the Github post just replaced with numbers.
jasode 5y ago
>I think this should link directly to Git's release notes (e.g. https://lore.kernel.org/git/xmqq1r6touqi.fsf@gitster.g/ https://lore.kernel.org/git/xmqq1r6touqi.fsf@gitster.g/), I disagree about that suggestion because I think it's less friendly for the wider more generalized HN audience. The very 1st sentence of the blog post already has a helpful hyperlink ref for the "released Git 2.33" that points to the official Git mailing list post. >The open source Git project just <released Git 2.33=="lore.kernel.org..."> with features and bug fixes from over 74 contributors, 19 of them new. The rationale for why I believe this is better for most casual readers: - The blog post has extra context and nice illustrations and lets more hardcore readers also discover the Junio C Hamano's mailing list post for Git. - But the reverse direction of information discovery is not as easy... if HN thread submission was the Junio C Hamano email text, there are no (reciprocal) links to the blog post by Github. Sometimes, the urge to avoid posts from <megacorporation> is reader hostile. ADD EDIT reply to : >OR it can link to the blogpost with a different title. I thought this was superfluous/redundant since "(github.blog)" in parentheses -- is already the composited title of the thread even if the submitter didn't put "Github" in the title. >I did not notice an objection to linking to a mega corporation. It was a general response to 3 comments (so far) I saw that indirectly complained about this thread being a Github blog post instead of something official from a Git maintainer such as a Junio C Hamano email.
- gugagore 5y ago
  You're not really responding to the comment. The comment is that it should link to the release notes if it keeps the title OR it can link to the blogpost with a different title. I did not notice an objection to linking to a mega corporation.
- deleted 5y ago
  [deleted]
- capableweb 5y ago
  I think my previous comment (https://news.ycombinator.com/item?id=28208138 https://news.ycombinator.com/item?id=28208138) highlights why it's problematic to link to release notes from an organization that is not the same organization that actually does the work/releases. In this case, GitHub didn't mention anything about `send-email`, because it's a direct competitor to themselves.
rattray 5y ago
The title of the post is "Highlights from Git 2.33" which implies less ownership - perhaps the submission title should be changed to that?
will4274 5y ago
> posts like this reinforce the common and unfortunate image that it is. Do they really? The first sentence of the post begins "The open source Git project" - it seems to me that this blog post could only reinforce that incorrect perception in people who didn't read it.
- CRConrad 5y ago
  What about "The open source Git project" is it that says this isn't posted by it?
lobo_tuerto 5y ago
Or title changed to the actual title on the post: "Highlights from Git 2.33"

by chucky 5y ago

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).

throwawayswede 5y ago

Not to mention that the actual Git release note includes the names of new and returning contributors, which the Github post just replaced with numbers.

jasode 5y ago

>I think this should link directly to Git's release notes (e.g. https://lore.kernel.org/git/xmqq1r6touqi.fsf@gitster.g/ https://lore.kernel.org/git/xmqq1r6touqi.fsf@gitster.g/), I disagree about that suggestion because I think it's less friendly for the wider more generalized HN audience. The very 1st sentence of the blog post already has a helpful hyperlink ref for the "released Git 2.33" that points to the official Git mailing list post. >The open source Git project just <released Git 2.33=="lore.kernel.org..."> with features and bug fixes from over 74 contributors, 19 of them new. The rationale for why I believe this is better for most casual readers: - The blog post has extra context and nice illustrations and lets more hardcore readers also discover the Junio C Hamano's mailing list post for Git. - But the reverse direction of information discovery is not as easy... if HN thread submission was the Junio C Hamano email text, there are no (reciprocal) links to the blog post by Github. Sometimes, the urge to avoid posts from <megacorporation> is reader hostile. ADD EDIT reply to : >OR it can link to the blogpost with a different title. I thought this was superfluous/redundant since "(github.blog)" in parentheses -- is already the composited title of the thread even if the submitter didn't put "Github" in the title. >I did not notice an objection to linking to a mega corporation. It was a general response to 3 comments (so far) I saw that indirectly complained about this thread being a Github blog post instead of something official from a Git maintainer such as a Junio C Hamano email.

gugagore 5y ago
You're not really responding to the comment. The comment is that it should link to the release notes if it keeps the title OR it can link to the blogpost with a different title. I did not notice an objection to linking to a mega corporation.
deleted 5y ago
[deleted]
capableweb 5y ago
I think my previous comment (https://news.ycombinator.com/item?id=28208138 https://news.ycombinator.com/item?id=28208138) highlights why it's problematic to link to release notes from an organization that is not the same organization that actually does the work/releases. In this case, GitHub didn't mention anything about `send-email`, because it's a direct competitor to themselves.

rattray 5y ago

The title of the post is "Highlights from Git 2.33" which implies less ownership - perhaps the submission title should be changed to that?

will4274 5y ago

> posts like this reinforce the common and unfortunate image that it is. Do they really? The first sentence of the post begins "The open source Git project" - it seems to me that this blog post could only reinforce that incorrect perception in people who didn't read it.

CRConrad 5y ago
What about "The open source Git project" is it that says this isn't posted by it?

lobo_tuerto 5y ago

Or title changed to the actual title on the post: "Highlights from Git 2.33"