Git 2.33
github.blog
github.blog
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.
In this case, GitHub didn't mention anything about `send-email`, because it's a direct competitor to themselves.
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?
Gonna need a source on this one.
I did not notice an objection to linking to a mega corporation.
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.
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
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.
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.
LFS makes a 'centralised' assumption about Git usage. Git is designed to be decentralised, even if that's not how we use it, whereas LFS requires a single central object store. An example of where this is a problem: we do a lot of development for clients. It's very convenient to be able to mirror the git repo to their Gitlab and git usually makes it very easy. If you have LFS in your project then you have to jump through a lot of hoops.
The second problem is that LFS copies its data exclusively via https. This creates some security complexity if you normally authenticate via SSH.
Regardless, I'm going to be sad if the UX we get to replace it is any of the newish/cutting-edge Git features, because they're damn ugly. In fact, despite how annoying LFS is for being a separate thing and requiring extra effort for server-side support if you're self-hosting, given Github and Gitlab (among others) support for LFS, I don't see things like sparse-checkout replacing it unless they get a lot nicer to use for that purpose specifically.
One thing that might help would be for Git to make distributing & sharing default repo config easy and built-in. Only thing that gets that treatment is the .gitignore. I feel like I need source control for my source control config, sometimes, and, indeed, some software's cropped up to do just that for e.g. hooks, but that ought to be built-in and cover more than that. One nice thing about LFS is that there's zero client-side config, aside from installing & enabling it (globally, if you like). You don't have to pass around lists of LFS-managed files or checkout-patterns or set-up scripts (hope you made them idempotent!) or anything out-of-band.
I don't quite get this point. The .gitattributes file is key to the operation of LFS and is modified and passed around in exactly the same way as .gitignore.
A good built-in implementation should do exactly what LFS does, yes. But they don't. LFS does, and that's part of why it's nicer to use for its specific purpose than doing something with shallow clones and sparse checkouts and all the rest. The best way to replace LFS in git itself would be to copy its UI as completely as possible, because it's pretty good.
Having to install & enable it is a pain, which making it part of git would fix. Having to maintain separate support for it server-side, and a separate transport mechanism, is a pain, which making it part of git at least could fix if the authors wanted to (in fact, I'd think it'd be more work not to solve that problem, in implementing it, though it'd leave vendors who want the two to be significantly separate to fend for themselves)
In addition, one lists MS. Not sure if that counts.
If you restrict yourself to contributions since Jan 1, 2020, you'll even find 4 "proper" Github employees in the top 10, and the 1 MS employee.
Another big factor contributing to it's popikaroty was that the Linux kernel (that even when git came out was a pretty big codebase already) also used it to great success.
The only real credit that can be given to GitHub in my eyes is that it allows individuals to more easily host remote repos.
GitHub launched in Feb 2008, Git soared and SVN plummeted.
https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...
No, they're just describing the new features... that does not mean GitHub actually wrote these features.
> In a previous blog post, we discussed how GitHub was using a new mode of git repack to implement our repository maintenance jobs. In Git 2.32, many of those patches were released in the open-source Git project
It looks like GH needed a better algo for git repack. Implemented a better algo for git repack. And contributed the better algo for git repack to the open source project. You can now use the better algo for git repack yourself without using GH.
It's fair to say they made the change
This work is slow, and a lot of the progress seems to be driven by the Google Summer of Code program (sort of like open source interns), so I suspect it will be a while before all the shell scripts are rewritten.
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”?
Because there are no robust, debugged standard library functions that have existed for years in 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".