LWN: Comments on "Git considers SHA-256, Rust, LLMs, and more"

A couple small clarifications

newren — Tue, 21 Oct 2025 23:23:16 +0000

Thanks for the article. Overall, it's a nice high-level overview of some recent happenings in Git. There's two small things I wanted to call out:

> Git, since the beginning, has used the SHA-1 hash algorithm

Actually, it uses sha1dc (https://github.com/cr-marcstevens/sha1collisiondetection) by default since about Git 2.13 (2.40 if on mac). sha1dc returns the same thing as sha1 on most all inputs, but on inputs where sha1 has certain already-published weaknesses it yields a different result. That provides a little bit of extra protection, though the need to move on to a better hash still stands.

> Elijah Newren said that he has already contributed some LLM-generated documentation

I think that summary is prone to mislead or at least be misunderstood; perhaps if you said "LLM-edited" rather than "LLM-generated"? To me, the latter implies the LLM was generating lots of new prose, which it wasn't. I was feeding the LLM existing documentation and telling it look for typos, grammatical errors, and awkward wordings and provide suggested corrections. I then (heavily) filtered (and perhaps even further edited) the output, divided it up into logical commits, and submitted it all a few years ago, and was fully up-front about what I was doing at the time. I think that's a good use of an LLM that an open source project shouldn't ban (and suggested a couple others), but it looks like I might lose on that point.

main branches locally

myUser — Tue, 21 Oct 2025 21:22:01 +0000

> I almost always wish my local repositories and my github forks could avoid having a local main branch at all. My workflow is that *every* change always happens on a branch, from which I create a pull request.

Why then not just delete it? Yes it is created after cloning, but you can then just get rid of it for good.

main branches locally

iabervon — Tue, 21 Oct 2025 21:15:09 +0000

In your local repositories, you can just checkout origin/main and then branch -d main. It's a hassle that it creates it, but you don't need to keep it if you don't want to. (Alternatively, you can just use branch -m to turn it into the first local branch you want.)

main branches locally

josh — Tue, 21 Oct 2025 19:18:36 +0000

I almost always wish my local repositories and my github forks could avoid having a local main branch at all. My workflow is that *every* change always happens on a branch, from which I create a pull request.

So, in a local repository, I always want every new branch to start from origin/main, not main, and I never want main to point to anywhere other than origin/main. And in a remote fork, main is nothing but a stale mirror of some ancient version of the base repo, because I never push to it except by mistake (creating a pull request from my main branch because I forgot to make a local branch, which is a pain).

The only time I ever want a local main branch is for the rare project where I commit directly to main, such as private one-person repositories.

master/main change

NYKevin — Tue, 21 Oct 2025 17:11:02 +0000

Don't do that. Use [1] and write a five-line bash script instead. It will save you so much time over manually nano'ing individual HEAD files one at a time.

[1]: https://git-scm.com/docs/git-symbolic-ref

master/main change

jhe — Tue, 21 Oct 2025 16:24:06 +0000

Thats what im doing (nano'ing the HEAD because git switch refuses to work in a bare repository) with the 1500 git mirrors. Whack-a-mole but on payroll.

master/main change

NYKevin — Tue, 21 Oct 2025 16:04:16 +0000

Usually you can just git switch main and it will figure itself out (--guess is on by default).

If you have more than one remote, you can (I think) write something like git switch -t origin/main. If you have local changes, you'll have to decide what to do with them, and there are flags for that (see git-switch(1)).

gitk

adobriyan — Tue, 21 Oct 2025 15:42:51 +0000

If gitk doesn't work with SHA-256 repo for you, clone gitk from https://github.com/j6t/gitk.git

This is what is pulled into git's git. alias gitk='~/distfiles/git/gitk.git/gitk'.

Google told me that 2.42 should be OK except even 2.49 doesn't have latest gitk usable with SHA-256.

This is LLMs for you.

master/main change

jhe — Tue, 21 Oct 2025 15:40:51 +0000

How would i keep the HEAD symrefs up-to date when upstream projects change from master to main? Every time upstream deletes the branch that previously was their HEAD, all mirrors of that repo end up with a dangling symref. Current solution is doing a fresh git clone, but this is not sustainable for upstream.