Git is not owned or stewarded by Github, and posts like this reinforce the common and unfortunate image that it is.
Git is not owned or stewarded by Github, and posts like this reinforce the common and unfortunate image that it is.
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.
I did not notice an objection to linking to a mega corporation.
In this case, GitHub didn't mention anything about `send-email`, because it's a direct competitor to themselves.
Gonna need a source on this one.
You're characterization of it being "problematic to link to Github" vs Git's official mailing list is overlooking the cause & effect of how stories end up on the front page. If most readers would prefer more "official" links from domain *.kernel.org, people can submit them, as they have done so in the past. Examples:
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Of course, after submission, people also need to upvote them. It's wrong (and misleading) to later change a submission linking to Github blog to the kernel.org url. The upvoters may have found the context and explanations from Github's post to be more helpful than the kernel.org post. (And as stated before, the Github post has the extra bonus of leading readers to the kernel.org release notes. But the opposite is not true, the kernel.org post does not lead to Github's extra explanations about the repack algorithm.)
In your opinion, where is the root cause of the "problem" as you call it? The submitters? The upvoters? The HN mods that leave the original thread url unchanged?
>In this case, GitHub didn't mention anything about `send-email`, because it's a direct competitor to themselves.
Hang on... let's level set here with some realism and not exaggerate. The "git send-email" is not a "direct" competitor to Github. Maybe GitLab could be described as a direct competitor.
Here's a previous thread where some folks don't want to mess with send-email because it's a hassle with a bunch of replies lecturing them that they're doing it wrong: https://news.ycombinator.com/item?id=13631069
It doesn't matter if those posters' complaints about send-email are wrong. The point is that send-email caters to a different type of git user and it's not a direct threat to Github at all.
Also, if Github was truly worried about users defecting to "git send-email", why would they deliberately link to the official Git notes that highlights git send-email as the 1st bulllet point ?!?
If we entertained your theory that "git send-email" kills Github's business model, wouldn't they omit the link to keep readers in the dark?
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.
Not only that; editing the title is against HN submission guidelines. https://news.ycombinator.com/newsguidelines.html
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.
Yeah, I know which one I'm choosing (the latter).
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.