Rendered at 12:27:22 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jodersky 5 hours ago [-]
It's unfortunate that change IDs aren't considered. There was a discussion [1]
in 2025, and it has resurfaced a couple of times since.
Basically, the idea is to attribute a new kind of ID to an initial 'change'. During review, or whenever a commit is rebased, the change ID is kept, whereas the commit of course changes. This allows tooling to identify all previous versions of a change, and is what enables "per-commit" code review à la Gerrit [2] (which IMO is a much better experience than the branch-review-squash model that GitHub normalized). It's also used in jj, although I'm not familiar with that.
As of today, any tool that wants a change ID needs to somehow encode it in commit message bodies. The proposed discussion was about making a change ID a standard header field that git would natively keep across rebases.
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.
stabbles 3 hours ago [-]
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.
ncphillips 4 hours ago [-]
Having switched to jj I totally agree. Change IDs are a huge UX win.
lostmsu 39 minutes ago [-]
How is this different from branches?
jakub_g 32 minutes ago [-]
I'm looking forward to reftable to become the default. It solves many problems with branches, like branches with weird characters created with non-standard clients making a fetch impossible; case insensitive branches with "same" names doing the same; or impossible to create branch FOO because FOO/Something exists.
All those problems just go away when branches are no longer files on disk.
I enabled it in setup script of one large repo I maintain; the main issue is the incompatibility with some people's personal tooling based on libgit2 (some git status tooling in oh-my-zsh), but people do find workarounds.
notpushkin 4 hours ago [-]
> Try LWN for free for 0 month: no payment or credit card required.
Quite a generous offer!
</aside>
WCSTombs 12 hours ago [-]
`git add --resolved` is a wonderful idea, and definitely something I would start using.
moebrowne 5 hours ago [-]
It appears that BitBucket also does not currently support SHA256 hashes.
Waiting for 3.0 to land and emancipate us from our 'master's. Bringing about true social change, one SHA at a time.
GTP 2 hours ago [-]
Why not transitioning to SHA3 directly? IIRC lenght extension attacks are not currently feasible on SHA2, but still theoretically possible.
cesarb 1 hours ago [-]
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.
lolakutty 3 hours ago [-]
Will we ever get integer commit references like we have in mercurial ?
irishcoffee 1 hours ago [-]
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.
lolakutty 54 minutes ago [-]
Why, because it shifts?
That is not a problem for local use + constant repo state.
KolmogorovComp 12 hours ago [-]
Does it mean that when switching trop sha1 to sha256 you need to forcepush and rewrite all history? Wouldn’t that be a massive source of potential vulnerabilities?
schacon 3 hours ago [-]
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.
nextaccountic 8 hours ago [-]
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
em-bee 11 hours ago [-]
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.
infogulch 9 hours ago [-]
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.
nomel 12 hours ago [-]
I don't know much about this. How does that enable vulnerabilities exactly?
jayd16 12 hours ago [-]
Trusting a forced push w/o any other verification means nefarious history changes can be slipped in.
You can still verify the contents - the content blobs don’t change after the migration. Not sure if there’s a practical attack one could do but maybe
awesome_dude 6 hours ago [-]
Um. how do you verify the contents? The history is for the contents you now have, not what might have been
TacticalCoder 1 hours ago [-]
So Git, in version 3.0, is moving to SHA-256 by default for SHA-1 ain't considered that strong anymore but...
What about future attacks by quantum computers? Is Git safe from quantum computers for it's all hashes only? Or shall there be issues with quantum attacks?
I'm asking for there are several projects that are already moving to quantum-resistant schemes (like OpenSSH who uses an hybrid scheme [1]).
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.
krior 1 hours ago [-]
But their post-quantum-algorithm also uses sha256. Afaik only asymetric crypto is in danger from quantum computers.
TacticalCoder 42 minutes ago [-]
Ah it's interesting, AIUI cryptographic hashes are safe from quantum attacks (for there's an infinity of secrets that, once hashed, give a specific hash and hence somehow it's not possible to use a quantum computer to forge what you'd want).
And from the other comment, symmetric cryptography is safe too from QC attacks.
So it's apparently as you wrote: it's really only asymmetric crypto that is at risk.
rainworld 1 hours ago [-]
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/
brookst 45 minutes ago [-]
Thanks for the great link! This has been vexing me, as intuitively it seems like if quantum computers can test all factors they should be able to test all keys.
But the article helps. Basically Grover’s is not as potent as Shorr’s. And it seems like everyone is convinced there is no dramatically better quantum algorithm than Grover’s?
mitxela 57 minutes ago [-]
Good point here I had never thought about, but it's still good to upgrade to 256 bits when possible for peace of mind.
This has nothing to do with SHAttered
Razengan 4 hours ago [-]
I'm still looking for a simple way to "save" a snapshot of my work in git, without all the ceremony of stashing etc
gregoriol 3 hours ago [-]
What could be simpler than "$ git stash" and "$ git stash pop" ?
m000 3 hours ago [-]
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.
leni536 3 hours ago [-]
I always just create a branch
moebrowne 2 hours ago [-]
I used to do this purely so that I could attach a name, then I found out that you can add a message when stashing: `git stash push -m "trying a thing"`
globular-toast 7 hours ago [-]
Why am I not surprised that GitHub is dragging its heels on sha256? I assume they just aren't able to change fundamental parts of their system now. So no sha256, no IPv6 etc. They can only sprinkle bits around the edges.
masklinn 5 hours ago [-]
TFA literally notes that one if the key sha256 devs is a github employee and in favor of the transition.
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.
coliveira 9 hours ago [-]
Somehow we have binary file format parsers written in C everywhere, so the real world shows it is possible and we do have programmers capable of doing it.
112233 8 hours ago [-]
Somehow we also have memory safety bugs everywhere, too. So real world shows bugs in C code are possible. What even is your argument? Real men write asm?
jcranmer 9 hours ago [-]
Sure, we can write a binary file format parser in C. We just can't figure out how to write one that isn't buggy and lets someone infect your computer if you give it sufficiently inventive garbage.
eviks 9 hours ago [-]
The issue isn't whether it's possible to have parsers, but whether it's possible to have them be secure, and periodic CVEs "everywhere" suggest we don't
cxr 8 hours ago [-]
Aside from memory safety, which is solved by using a compiler that just doesn't allow unsafe memory operations (so not GCC or Clang upstream), which CVEs specifically would have been ameliorated by a parser written in Rust instead of C?
eviks 7 hours ago [-]
Aside from the fact that it's not solved by using an alternative compiler, why would you put the core advantage aside?
duskwuff 7 hours ago [-]
> Aside from memory safety, which is solved by using a compiler that just doesn't allow unsafe memory operations
I don't see how that's possible without turning the language into something that isn't C, either by adding significant new functionality (e.g. fat pointers) or subtracting enough functionality that it's a much less capable language (e.g. disallowing dynamic memory allocation).
An important improvement over rust is that "Fil-C has no unsafe statement."
rpadovani 6 hours ago [-]
As everything, there are compromises and prices to pay.
In case of fil-c, it is about 1.5-4x slower performance, and a memory overhead.
So, let's not present it as a panacea to all problems: there could good reasons to use it, but it isn't a magic trick.
GoblinSlayer 5 hours ago [-]
Rust is slower too, and git is IO bound anyway, and routinely calls bash.
serbuvlad 6 hours ago [-]
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.
epidemian 8 hours ago [-]
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?
devilsdata 5 hours ago [-]
Is all use of Rust "coerced" and "forced on everyone", or is there a way to write things in it that makes sense?
tombert 9 hours ago [-]
I don't think it's "just for the sake of it". I think they believe that the Rust code will be safer.
coliveira 9 hours ago [-]
If that's the case, they should stop using git and Linux right now, because it's everything written in C. Having 0.1% of the code in a safe language will not change anything, it's only a bad security blanket.
aw1621107 9 hours ago [-]
> Having 0.1% of the code in a safe language will not change anything, it's only a bad security blanket.
Just because something does provide an immediate perfect solution does not mean it isn't not worth investigating and/or pursuing.
Also consider that bugs tend to be more prevalent in new code (e.g., [0]) as a result, you are likely to see more of a benefit from writing new code in a memory-safe language than raw line count proportions would indicate.
You don't believe in slowly and iteratively improving a codebase over time? Should git stick with its weird mishmash of C and perl and shell scripts forever, for tradition's sake, performance and maintainability be damned?
devilsdata 5 hours ago [-]
I don't understand your reasoning. Why should they quit git and Linux (and presumably all applications written in C) if they believe Rust is more secure than C?
Joker_vD 4 hours ago [-]
It's the classic "Yet you participate in society. Curious!" response. You don't get dislike the current state of the world if you exists in it, apparently.
shakow 5 hours ago [-]
I hope you don't use seatbelts in your car, as they won't help you against a fire.
baq 6 hours ago [-]
Rewriting it all in rust with bug for bug compatibility and byte identical outputs won’t cost more than $100k in tokens, but I don’t think this is an answer you’re looking for
8 hours ago [-]
drgo 11 hours ago [-]
[flagged]
IshKebab 6 hours ago [-]
Are they going to fix all the bad defaults in Git 3.0?
onetoo 6 hours ago [-]
For reference, what would you say those bad defaults are?
(I would like to know if I should consider changing my configuration)
iib 5 hours ago [-]
There is a post[1] on the gitbutler blog where they collect a subset of defaults that allegedly git core developers use. It's where I got most of my config from.
1. Git push should default to --force-with-lease --force-if-includes.
2. push.autoSetupRemote should be enabled by default.
3. The default conflict style should be zdiff3.
4. diff.submodule should be 'log' by default (gives much nicer submodule diffs).
5. Submodule updates / clones should be recursive by default. (There is a setting for this but I can't remember it.)
Oxodao 4 hours ago [-]
rerere should be on
eviks 9 hours ago [-]
> It is a binary file optimized for both space efficiency and quick access. Since then, it has been possible to create a repository that uses a reftable rather than the old file-based mechanism,
Good, are there (m)any other plans to ditch the slow files and use proper database? Or is it only reserved for various post-git competitors?
cesarb 8 hours ago [-]
> 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.)
spankalee 7 hours ago [-]
There are lots of places it'd be useful to use Git that don't have filesystems.
eviks 7 hours ago [-]
> more than a few hundred refs
Ah, yeah, "you're holding it wrong", though use cases haven't changed, it's closer to the expected common case of expectations turning out wildy wrong (Why would you ever expect people to stop NAMING things at scale???)
But also the core property of the filesystem database has always been low performance for a bunch of tiny things
schacon 3 hours ago [-]
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.
112233 8 hours ago [-]
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?
ithkuil 2 hours ago [-]
It's not just slowness, but what about case insensitive filesystems?
Basically, the idea is to attribute a new kind of ID to an initial 'change'. During review, or whenever a commit is rebased, the change ID is kept, whereas the commit of course changes. This allows tooling to identify all previous versions of a change, and is what enables "per-commit" code review à la Gerrit [2] (which IMO is a much better experience than the branch-review-squash model that GitHub normalized). It's also used in jj, although I'm not familiar with that.
As of today, any tool that wants a change ID needs to somehow encode it in commit message bodies. The proposed discussion was about making a change ID a standard header field that git would natively keep across rebases.
[1] https://lore.kernel.org/git/Z_OGMb-1oV0Ex05e@pks.im/T/#mf941...
[2] https://gerrit-review.googlesource.com/Documentation/user-ch...
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.
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.
All those problems just go away when branches are no longer files on disk.
I enabled it in setup script of one large repo I maintain; the main issue is the incompatibility with some people's personal tooling based on libgit2 (some git status tooling in oh-my-zsh), but people do find workarounds.
Quite a generous offer!
</aside>
https://jira.atlassian.com/browse/BCLOUD-23729
That is not a problem for local use + constant repo state.
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.
Failing that, have a kind of git object that wraps another and says hey this is in sha1 don't mess with it
What about future attacks by quantum computers? Is Git safe from quantum computers for it's all hashes only? Or shall there be issues with quantum attacks?
I'm asking for there are several projects that are already moving to quantum-resistant schemes (like OpenSSH who uses an hybrid scheme [1]).
[1] https://www.openssh.org/pq.html
And from the other comment, symmetric cryptography is safe too from QC attacks.
So it's apparently as you wrote: it's really only asymmetric crypto that is at risk.
But the article helps. Basically Grover’s is not as potent as Shorr’s. And it seems like everyone is convinced there is no dramatically better quantum algorithm than Grover’s?
This has nothing to do with SHAttered
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.
And sha256 is in private preview at GitHub: 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.
I don't see how that's possible without turning the language into something that isn't C, either by adding significant new functionality (e.g. fat pointers) or subtracting enough functionality that it's a much less capable language (e.g. disallowing dynamic memory allocation).
An important improvement over rust is that "Fil-C has no unsafe statement."
In case of fil-c, it is about 1.5-4x slower performance, and a memory overhead.
So, let's not present it as a panacea to all problems: there could good reasons to use it, but it isn't a magic trick.
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.
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?
Just because something does provide an immediate perfect solution does not mean it isn't not worth investigating and/or pursuing.
Also consider that bugs tend to be more prevalent in new code (e.g., [0]) as a result, you are likely to see more of a benefit from writing new code in a memory-safe language than raw line count proportions would indicate.
[0]: https://security.googleblog.com/2024/09/eliminating-memory-s...
[1] https://blog.gitbutler.com/how-git-core-devs-configure-git
1. Git push should default to --force-with-lease --force-if-includes.
2. push.autoSetupRemote should be enabled by default.
3. The default conflict style should be zdiff3.
4. diff.submodule should be 'log' by default (gives much nicer submodule diffs).
5. Submodule updates / clones should be recursive by default. (There is a setting for this but I can't remember it.)
Good, are there (m)any other plans to ditch the slow files and use proper database? Or is it only reserved for various post-git competitors?
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.)
Ah, yeah, "you're holding it wrong", though use cases haven't changed, it's closer to the expected common case of expectations turning out wildy wrong (Why would you ever expect people to stop NAMING things at scale???)
But also the core property of the filesystem database has always been low performance for a bunch of tiny things
This is work that Patrick and GitLab have been doing for years now and it's very impressive and nearly complete.