Looking forward to Git 2.56 – and 3.0

JJ and GitButler already create and inject this into the commit headers (using the same interoperable reverse-hex format), which is recognized by Gerrit and some forges like Tangled for incremental commit based review.

I doubt that core Git will adopt it anytime soon as it was not discussed at this years contributor summit (last week) and doesn't seem to be a hot topic on the ML.

What I would like to see is support for `git rebase` not dropping it, which is the current main issue. The `git replay` command, as well as commands based on the same sequencing code (`git history` for example) do not drop custom headers like this, so there is partial non-breakage, but several of the other history editing commands do drop custom headers.

Having switched to jj I totally agree. Change IDs are a huge UX win.

Yeah, "standardizing" change IDs would make it much easier to develop further tooling around it. In particular decentralized review is something that I'd be interested in.

For example, if GitHub is down, that would not be a blocker to access review comments or to do reviews. And maybe you could push your reviews to a GitLab mirror if you want a UI.

How is this different from branches?

It's much, much worse than that.

Yes, you do need to do that. However, there is also much more work after that.

Git will not intermingle SHA-256 and SHA-1 enabled repositories, even in things like submodules, so anything used in that manner will need to keep both versions into the indefinite future. If you rely on a submodule that has not yet converted, you will have to convert it yourself and try to keep it up to date, or the forge will have to automatically keep a bidirectional mirror (if you have submodules in various forges, you'll have to wait for all of them to do it), etc.

This means that every SHA referenced anywhere on the internet, in commit messages, in issues, in code comments is now invalid and needs a mapping to find the rewritten one for forever.

It also means that every commit signature ever made is now invalid and will probably have to be stripped from the rewritten new 256 history because it's impossible to resign everything.

Companies like Google and GitHub are working on keeping two versions of each repository so that there can be long stages of ecosystem migrations, but no matter what, it's going to be a huge pain for millions of developers for years to come.

That's odd. Why not compute both sha1 and sha256 for all git objects for the foreseeable future?

Failing that, have a kind of git object that wraps another and says hey this is in sha1 don't mess with it

It is a giant format change, but in the current documentation [0] sounds more like a repack than a force-push. git keeps a lookup table of the SHA1 object ids similar to an index file and some interop is allowed between SHA1 repositories and SHA256. (Primarily if you still needed to use GitHub as an SHA1 server because of some support hiccup, but needed your local repo to be SHA256 for security or other reasons, that's partially/mostly supposted.) Objects need to be resigned with their SHA256 id, but for different reasons than rebase/force-push and with a subtly different developer experience. In theory using that compatibility index of SHA1 hashes a good UI could show both signatures.

[0] Migration document: https://git-scm.com/docs/hash-function-transition

i guess that for now only the default will change for new repositories. support for sha1 is not going to be dropped, so most existing repositories won't switch any time soon. if you want to switch then yes, it sounds like a force push might be needed, although it could also be that simply switching is not possible, but that instead you have to create a new repo and import the history from the old repo, forcing everyone to clone the new repo intentionally.

Couldn't you write something that checks every commit's content and message is byte equal to the old tree? One scan through the history to verify it should be relatively simple if not cheap. Should be built into git.

I don't know much about this. How does that enable vulnerabilities exactly?

Length extension attacks are not an issue for git, because every object has two fields in its header, which is prepended to the object before hashing: the object type and the length in bytes.

I will always mourn hg losing to git in the DVCS wars, however it was generally considered bad practice to rely on the integer commit references.

But their post-quantum-algorithm also uses sha256. Afaik only asymetric crypto is in danger from quantum computers.

As far as I understand, quantum computing can cut it in half, to 128 effective bits. Still way too large to brute force from there.

At this point, it does not appear that (reasonably strong and modern) symmetric cryptography (ciphers, hash functions, etc.) is realistically threatened by quantum computing: https://words.filippo.io/128-bits/

Create a WIP branch, and keep working in there committing as often as you want, then squash the history if you don't want it all when you are ready to put the changes in the “real” branch that you are working on?

What I've done since before git was a thing is a variant of my backup process: my main work areas are synced using rsync⁰ to a copy¹ that is the head of a series of snapshots. If this ends up containing any newly created/modified files²³ a new snapshot is created using `cp -al`. This way I don't have to remember to commit regularly, and I have an automatic trace of everything I've done to a certain granularity⁴. The snapshots are given a name based on the contents of a text file, if present, so I can label points in time (otherwise the snapshot names are just timestamps). Tidying up is easy, just delete old snapshots with `rm -rf`, you could automate this if you like⁵ but I've never felt the need to. The not having to remember to do anything is key for me - over the years it has saved me⁶ from harmful edits not noticed for some time that might otherwise have been more of a pain to recover from. You could do similar per repo with the WIP-branch-in-git option: have script that scans for projects in that named branch, for any found check `git status`, if there are any changes commit with the timestamp as the commit message.

--------

[0] set to ignore a few things like .git directories and some artefacts that I would list in .gitignore

[1] off on a server, that isn't key but it does give me protection against the work machine going boom as well as from accidents off my own doing

[2] detected by looking for files with only one link to them, this can be an expensive check over huge numbers of files but not for what I'm using it on

[3] the sync deletes files too, though I don't use such changes on their own as a reason to create a new snapshot

[4] much higher than the 24-hour granularity that my normal backups have, about 1440 times smaller in fact

[5] keeping them for a maximum amount of time, perhaps, and/or more complex heuristics like not keeping too many copies that are only a few minutes or less apart

[6] only a few times, but more than enough to make me glad I implemented it!

What could be simpler than "$ git stash" and "$ git stash pop" ?

Not sure what you are looking for. What's wrong with stash? What ceremony are you referring to? `git stash` - `git stash pop` is as simple as it gets.

Then you can also do `git diff > changes.diff`. Or simply `rsync -avPh repo/ repo.snap/`, if your repo isn't huge. Or consider putting your repo in a filesystem that can do CoW snapshots.

I always just create a branch

TFA literally notes that one if the key sha256 devs is a github employee and in favor of the transition.

And sha256 is in private preview at GitHub: https://github.com/bk2204/talk-rust-in-git/blob/dev/presenta...

They don't seem to have any problems cramming in ever more AI garbage down our throats.

Priorities!

It is on the horizon: https://github.com/bk2204/talk-rust-in-git uses SHA256

For reference, what would you say those bad defaults are? (I would like to know if I should consider changing my configuration)

The comments gives a link to a recent talk about the motivation for using Rust in Git: https://github.com/bk2204/talk-rust-in-git/blob/dev/presenta...

I wouldn't agree with all of those reasons, but it's very definitely not "just for the sake of it." One of the better reasons so many people look to writing some things in Rust is that we now have pretty ample evidence than trying to write a binary file format parser in C is a cornucopia of CVEs that are just simply absent in Rust, and the excuse of "well, but a sufficiently smart programmer doesn't write bugs in C" doesn't cut it anymore.

fwiw, the use of C is infinitely more "coerced" than the use of Rust.

on my Linux system, C takes ownership of a 'top-level' /usr/include directory, all the kernel APIs have their canonical definitions in C headers, a lot of system features like nsswitch require dynamically linked C libraries etc. etc.

Rust is just something that programs can choose to be written in and that doesn't inconvenience me in any way.

Of the codebases i know that have adopted Rust, it has always been because some of their maintainers wanted to do so.

Maybe git's case is different though. Do you have more info about it? Are you a git maintainer who was coerced to use Rust, or do you know of such cases?

I don't think it's "just for the sake of it". I think they believe that the Rust code will be safer.

Is all use of Rust "coerced" and "forced on everyone", or is there a way to write things in it that makes sense?

> Good, are there (m)any other plans to ditch the slow files and use proper database?

The filesystem is a proper database, just not a relational one.

Linus focused heavily on performance when he wrote git; he used the filesystem because, as the main Linux kernel maintainer, he knew that the Linux VFS and filesystems were fast enough for these use cases.

(It's the use cases that have changed; it was not expected back then to have more than a few hundred refs in a single repository.)

Yes, Patrick Steinhart (GitLab) has been working not only on reftables and pluggable backends for the references data, but also pluggable backends for object storage, so that you can use any database backend format (sqlite, s3, special large file storage options, etc) to store objects if you want (in addition to loose objects and packfiles).

This is work that Patrick and GitLab have been doing for years now and it's very impressive and nearly complete.

By "proper" I assume you mean relational? Or ACID? Or you mean using existing database software? What is so improper about the way git stores data?

It's not just slowness, but what about case insensitive filesystems?