4 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 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 agoYou'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 agoI 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.
- tyre 5y ago> because it's a direct competitor to themselves. Gonna need a source on this one.
- capableweb 5y agoSource? GitHub is meant for collaborating on Git repositories. One of the main features they have are Pull Requests, which basically is the `send-email` feature but without email, with a web UI and some other features on top of PRs.
- sofixa 5y agoSo in the same way that say, a motorcycle and a car are competitors. You can use them for some of the same things ( move yourself), but one of them does many more things.
- nextaccountic 5y agoWe can speculate on why they would omit such a thing, but there's a clear conflict of interest here.
- jasode 5y ago>I think my previous comment ([...]) 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. 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&query=git%201.%20.kernel.org&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=git%202.%20.kernel.org&sort=byPopularity&type=story 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 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?