Git 2.33

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.

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.

LFS is a hack and a workaround for the fact that git ships the whole thing and requires you to have every copy of every blob from the whole of history.

LFS cheats this by storing the big blobs elsewhere and only fetching the ones needed for your checkout. It's a giant pain as everyone knows because you've got two sources of data. Instead lots of work is being done on git to remove the "every copy of every blob" requirement. This is in 2 dimensions - only some specified depth of history, and only some subset of the checkout (LFS only helps with the first). Effectively you still only end up fetching the blobs you need from the server for the checkout you're doing. That gets the same benefit of LFS but all in core git.

When you are writing and debugging something new, you don’t want it to take forever to get it into a correct state. When you are maintaining things, you want readable code. And in an open-source project, you might attract more maintainers if you have code that is more accessible (e.g. simple things appear as simple as they are because they’re scripts, and people familiar with those languages can help even if they are not C programmers). It is also more likely to work cross-platform.

I can imagine a lot of things that would be a very simple few lines of script but a mess to write, debug and read in C code. This is especially true if you could have (say) relied on a robust, debugged Python standard library function that has existed for years but instead had to do all of that yourself in C “because the project should only be using C”?

But specifically, the ORT strategy can cache computed renames across multiple commits being rebased, so the performance benefits are even greater for "git rebase".