Looking forward to Git 2.56 – and 3.0

120 pointsposted 10 hours ago
by chmaynard
(lwn.net)

28 Comments

jodersky

an hour 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.

[1] https://lore.kernel.org/git/Z_OGMb-1oV0Ex05e@pks.im/T/#mf941...

[2] https://gerrit-review.googlesource.com/Documentation/user-ch...

ncphillips

an hour ago

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

WCSTombs

9 hours ago

`git add --resolved` is a wonderful idea, and definitely something I would start using.

Razengan

11 minutes 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

a few seconds ago

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

notpushkin

an hour ago

> Try LWN for free for 0 month: no payment or credit card required.

Quite a generous offer!

</aside>

globular-toast

3 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.

KolmogorovComp

9 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?

nextaccountic

5 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

8 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

6 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

9 hours ago

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

jayd16

8 hours ago

Trusting a forced push w/o any other verification means nefarious history changes can be slipped in.

vlovich123

6 hours ago

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

2 hours ago

Um. how do you verify the contents? The history is for the contents you now have, not what might have been

IshKebab

2 hours ago

Are they going to fix all the bad defaults in Git 3.0?

onetoo

2 hours ago

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

IshKebab

2 hours ago

Here are a few:

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

30 minutes ago

rerere should be on

eviks

5 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

5 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.)

eviks

4 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

spankalee

3 hours ago

There are lots of places it'd be useful to use Git that don't have filesystems.

112233

5 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?