What’s new in Git 2.54.0?

Git 2.54.0 introduces foundational changes to Git’s storage and history-editing capabilities. Its object database is now pluggable, making alternative storage formats more feasible, while the new git history command simplifies common commit-history edits that previously required interactive rebases. These changes are early milestones in longer-term efforts to improve repository performance and support stacked-diff workflows.

Pluggable Object Databases

• Git already supports interchangeable reference backends, including files and reftable.
• Git 2.54 extends this abstraction to object databases, which store loose objects and packfiles under .git/objects.
• The work began in Git 2.48 and involved nearly 400 upstream commits over almost two years.
• Alternative object-storage implementations can now support meaningful local workflows, including:
  • Creating commits
  • Displaying commit graphs
  • Performing merges
• Remote operations such as fetching and pushing are not yet supported through alternate backends.
• Future storage formats could:
  • Handle large binary files more efficiently than packfiles
  • Be optimized for GitLab’s repository-serving infrastructure
• The project was led by Patrick Steinhardt.

Easier Commit-History Editing

• Developers often rewrite history to produce small, atomic commits with clear messages, but interactive rebases can be difficult to learn.
• Interactive rebases require users to choose a base commit, edit an instruction sheet, and understand Git’s stateful rebase process.
• Git 2.54 introduces git history, inspired partly by Jujutsu’s simpler history-editing commands.
• Initial subcommands include:
  • git history reword: change a commit message
  • git history split: divide one commit into two by selecting which changes belong in each
• Planned commands include:
  • git history fixup
  • git history drop
  • git history reorder
  • git history squash
• The command can automatically rebase local branches that contain the edited commit, including branches other than the current one.
• This behavior supports Git’s broader effort to improve stacked-diff workflows, where dependent branches are reviewed independently.
• The project was led by Patrick Steinhardt with support from Elijah Newren.

The release points toward a more extensible Git: repository storage can eventually be optimized for different workloads, while history editing becomes more approachable than traditional interactive rebases. Since both features are still developing, users should expect broader backend support and additional history commands in future releases.