Git 2.46.0 released

[Posted July 29, 2024 by corbet]

Version 2.46.0 of the Git source-code management system has been released. This release seems to consist of a long list of interface and performance improvements rather than big new features; see the announcement for the details.

More details from GitHub blog

Posted Jul 29, 2024 20:06 UTC (Mon) by epa (subscriber, #39769) [Link] (22 responses)

https://github.blog/open-source/git/highlights-from-git-2...

More details from GitHub blog

Posted Jul 29, 2024 21:35 UTC (Mon) by atnot (subscriber, #124910) [Link] (21 responses)

As nice as these are, I always find it a tad sad that this detailed, user-facing writing has to be under the github banner and not part of the git project itself, only serving to further reinforce the synonymousness of git with github in the eyes of many.

More details from GitHub blog

Posted Jul 29, 2024 22:12 UTC (Mon) by rmano (guest, #49886) [Link] (3 responses)

Well, as lot of things in the free software world, the problem is that you need someone that *does* the writing. I don't find at all sad that GitHub consider that important, and maybe pay somebody to do it, and that everybody can enjoy that work. The other option is to do the work, and to write it under another banner.

More details from GitHub blog

Posted Jul 29, 2024 22:30 UTC (Mon) by gus3 (guest, #61103) [Link] (2 responses)

"Git" is not the same as "GitHub", which is now owned by Microsoft.

More details from GitHub blog

Posted Jul 30, 2024 6:26 UTC (Tue) by gspr (subscriber, #91542) [Link]

This point was already made in the grandparent post. The parent post just argued how it might be considered a good thing that GH/MS spends money to have someone write a nice article about a new release of git. That in no way entails equating the two.

More details from GitHub blog

Posted Jul 30, 2024 8:30 UTC (Tue) by smcv (subscriber, #53363) [Link]

Linux isn't the same thing as Linux Weekly News, yet here we are, reading about edited highlights of Linux kernel releases (among other things) as summarized by writers who were not responsible for making the release themselves. And that's fine! If the Linux kernel release managers aren't required to do that work, they can spend their time making more and/or better releases instead.

We could say the same about Git.

More details from GitHub blog

Posted Jul 30, 2024 5:54 UTC (Tue) by oldtomas (guest, #72579) [Link] (15 responses)

This is part of Microsoft's strategy of making software development into a social media thing.

They missed the search engine train (they're still trying to catch it, cf. DuckDuckGo). They missed "general" social media to Facebook and Twitter.

So they turned to software professionals. LinkedIn. The acquisition of Github must have been well-prepared (I mean: they drown in money, but shelling out $7.5B might take some compelling plan). VSCode is the other piece of the puzzle (the "front end", comparable to Google's Android, if you will).

I don't like the turn things are taking. I liked Git from the get-go -- after years of CVS, some SVN ("Oh!... mmm... no"), watching the other contenders (Arch, TLA, its mutation into that Canonical thing, Hg, Darcs...) -- Git made "click".

It took some learning, but, boy was it worth it.

Github, to me, was a bad idea from the beginning. Making a genuinely decentralized thing into a centralized service, and this at the hands of a company, which can be swallowed by a bigger one with a nefarious agenda... told you so.

More details from GitHub blog

Posted Jul 30, 2024 6:07 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

> This is part of Microsoft's strategy of making software development into a social media thing.

Why is this bad? Microsoft wants to make sure that they stay relevant, and makes a product that is useful.

> Github, to me, was a bad idea from the beginning. Making a genuinely decentralized thing into a centralized service, and this at the hands of a company, which can be swallowed by a bigger one with a nefarious agenda... told you so.

This is a reason to support other software, like Gitlab and to make sure your package infrastructure does not depend on Github staying up. Archiving public data would also be a good idea.

The thing is, this should be done regardless of who owns a service.

More details from GitHub blog

Posted Jul 30, 2024 21:57 UTC (Tue) by ballombe (subscriber, #9523) [Link] (7 responses)

> This is a reason to support other software, like Gitlab and to make sure your package infrastructure does not depend on Github staying up. Archiving public data would also be a good idea.

gitlab is also a centralized service. It does not help propagating the decentralized mindset of git to developers,
quite the opposite.

More details from GitHub blog

Posted Jul 30, 2024 22:04 UTC (Tue) by pizza (subscriber, #46) [Link] (2 responses)

> gitlab is also a centralized service. It does not help propagating the decentralized mindset of git to developers,
quite the opposite.

How many folks have their own public server capable of hosting a git repo?

The PITA of setting up and maintaining a public revision control, bug tracker, etc etc etc is why "forges" became popular in the first place.

More details from GitHub blog

Posted Jul 31, 2024 13:07 UTC (Wed) by ballombe (subscriber, #9523) [Link] (1 responses)

> How many folks have their own public server capable of hosting a git repo?

This is the issue we need solve. However any web server is capable of hosting a git repo,
this should not be a barrier.

> The PITA of setting up and maintaining a public revision control, bug tracker, etc etc etc is why "forges" became popular in the first place.

Before GIT, CVS required a central server which lead to the need for forges, but it is not the case anymore and not every developers in a project need their own bug tracker. One bug tracker by project is sufficient in most case.

More details from GitHub blog

Posted Aug 1, 2024 1:32 UTC (Thu) by pizza (subscriber, #46) [Link]

> This is the issue we need solve. However any web server is capable of hosting a git repo, this should not be a barrier.

*should not* is emphatically not the same as *is not*

Again, it's not the difficulty of the initial setup of the server etc, but *maintaining* said server/services indefinitely. That costs time and/or money, on an ongoing, indefinite basis.

The "forges" are popular because they take care of all of that crap, so you don't have to. And for the overwhelming majority of folks, it costs them no money.

> Before GIT, CVS required a central server which lead to the need for forges, but it is not the case anymore and not every developers in a project need their own bug tracker. One bug tracker by project is sufficient in most case.

The moment more than one person wants to collaborate on the same codebase, you need some sort of canonical/central/authoritative place for the "true" source code, or synchronization rapidly becomes a nightmare. That is independent of the precise VCS or data transfer mechanism.

More details from GitHub blog

Posted Jul 30, 2024 22:29 UTC (Tue) by anselm (subscriber, #2796) [Link] (2 responses)

gitlab is also a centralized service. It does not help propagating the decentralized mindset of git to developers, quite the opposite.

Nothing prevents you from running your own Gitlab instance for the price of a fancy cup of coffee or two per month. Try that with Github.

More details from GitHub blog

Posted Jul 31, 2024 10:39 UTC (Wed) by yeltsin (guest, #171611) [Link] (1 responses)

I'd recommend taking a closer look at Gitea (or its fork Forgejo).

We've been using it for years (since 2019 IIRC) for self-hosting hundreds of git repositories and bug tracking, and it's been an absolutely painless experience. It uses barely any resources and upgrades do not require manual intervention or any noticeable downtime.

The built-in CI is mostly compatible with GitHub Actions, or you can use a third-party solution (most setups use Drone which is pretty much dead at this point; I probably wouldn't start with it anymore).

It still has a ways to go, but they have some features that are missing from the free/libre version of Gitlab (like multiple reviewers for a single PR).

https://docs.gitea.com/installation/comparison

More details from GitHub blog

Posted Jul 31, 2024 12:23 UTC (Wed) by anselm (subscriber, #2796) [Link]

I'd recommend taking a closer look at Gitea (or its fork Forgejo).

Absolutely. My main point was that it is disingenuous to think of Gitlab as a “centralised service” à la Github. The Gitlab people do operate a free public forge, but there are also lots of options for running your own instance (both free and paid-for versions with varying feature sets). Other forge-type packages exist.

More details from GitHub blog

Posted Jul 31, 2024 0:52 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

They key here is to have several centralized services that compete with each other.

More details from GitHub blog

Posted Jul 30, 2024 7:37 UTC (Tue) by epa (subscriber, #39769) [Link] (2 responses)

It could be a sinister plan by followers of the dark lord. Or it could be that Microsoft is a heavy user of git, with a particular interest in performance for its huge codebase, and so too are GitHub, who you might expect to write articles about git, whoever the company’s owners were.

More details from GitHub blog

Posted Jul 30, 2024 10:18 UTC (Tue) by jch (guest, #51929) [Link]

It could be both.

More details from GitHub blog

Posted Jul 30, 2024 13:42 UTC (Tue) by pawel44 (guest, #162008) [Link]

>It could be a sinister plan by followers of the dark lord.

Or it could be a lack of knowledge if you think there are no bad intentions behind it.

More details from GitHub blog

Posted Jul 30, 2024 11:34 UTC (Tue) by paulj (subscriber, #341) [Link]

The DuckDuckGo mention is a reference to it being powered by Bing? Or something else?

More details from GitHub blog

Posted Jul 30, 2024 11:59 UTC (Tue) by dskoll (subscriber, #1630) [Link] (1 responses)

I don't use GitHub heavily, though I have a project on it. However, if GitHub disappeared tomorrow, it wouldn't be a big deal to me. Yes, I'd lose PR discussions and issue tracking, but Git itself is decentralized and I'd just move on with my life.

My hobby projects are mirrored on three Git forge services: A self-hosted forgejo instance, Codeberg, and salsa.debian.org. Even the one I have on GitHub is mirrored on the other three.

More details from GitHub blog

Posted Jul 31, 2024 11:08 UTC (Wed) by yeltsin (guest, #171611) [Link]

FWIW, Gitea (Forgejo probably too) supports migrating features, releases, and pull requests from GitHub. It doesn't support synchronization, so you have to repeat it periodically. Here's the crontabbed script stripped to its absolute essence:

https://paste.debian.net/1324948

Delete the target repository each time (see gitea API docs in the footer), or add something like the current timestamp to get a unique name. I use a sequence of "sync under a temporary name → delete the old repo → rename the new one" to not lose any data.

The full list of GitHub repositories can be extracted with their API, and everything can be fully automated, but the endpoint you need depends on how your repos are set up.

More details from GitHub blog

Posted Jul 30, 2024 17:03 UTC (Tue) by thoughtpolice (subscriber, #87455) [Link]

I mean, writing user-facing detailed notes is a lot of work, to be fair. And where would they post it, as part of the Git project? The mailing list? The website has always been quite spartan and fairly static for the past many years, and it's my impression this is on purpose. There is no official blog of the project. They could just make it part of the release process itself too, so these were effectively the "release notes", but again, it's a lot more work than running git shortlog to do a big technical writeup like this.

It's a bit of a process change, no matter how you slice it. It would be nice if the Git project did have a place some stuff like this and hand technical writers on hand for it, though, but in lieu of that I'm alright with this.