// HACKER NEWS — CYBERSECURITY
Looking forward to Git 2.56 – and 3.0
The following subscription-only content has been made available to you
by an LWN subscriber. Thousands of subscribers depend on LWN for the
best news from the Linux and free software communities. If you enjoy this
article, please consider subscribing to LWN. Thank you
for visiting LWN.net!
The Git 2.56 release contains something over 700 non-merge commits; it
brings a number of nice improvements, but will not fundamentally change the
Git experience for most users. One feature that offers some potential in
that regard is the addition of the drop subcommand to the (still
experimental) git
history toolbox:
This command will cause the identified commit to be removed from the
history of the current branch, replaying all commits that were added after
it. It offers an easier way of removing an offending commit.
Unfortunately, it still refuses to work if the history contains merge commits,
making it unusable for many (or most) repositories.
The git status
command will now suggest a git pull command to
update a branch that is behind the branch it tracks. It still, though,
will say that a branch is "up to date" even if it lags behind an
(unfetched) remote tracking branch.
The git refs
command exists to manipulate references at a low level; in 2.56, it has
gained a number of new subcommands. Those commands, create,
delete, update, and rename, perhaps surprisingly
for Git, do exactly what their names suggest they would.
There are a number of minor usability tweaks. The new
--delete-merged option to git branch will
remove local branches that have been merged into their remote tracking
branches. An attempt to delete a branch with git branch -d will
fail, with a useful message, if that branch is being used for bisection.
Attempts to lock the configuration file will be retried on failures,
avoiding annoyance when multiple commands try to modify the file at once.
git add has a new
--resolved option that only adds files with merge conflicts that
have been resolved.
Beyond that, there is the usual long list of bug fixes, refactorings, and
performance improvements. All told, 2.56 looks like a solid release, but
it also shows the signs of a project that is holding back much of its more
significant work for the future. That leads to the question of what comes
next.
In early September, Git maintainer Junio Hamano asked the community what the
next release should be. Would it be best to put out the 3.0 release that
the community has been working toward for some time, finishing the year on
a high note? Or, instead, is there a need for one or more 2.x releases
still before the 3.0 release can happen?
This is an important question, because 3.0 will contain a number of
compatibility breaks that may make some users pause before upgrading. Of
those, perhaps the most significant is the switch to using the SHA-256 hash
function by default, rather than the SHA-1 hash that Git has used since the
beginning. SHA-1 has long been deemed to be weak, which is worrisome for
applications like Git. Hashes are used to identify every object (files,
directory trees, commits) in the Git repository, and are used to verify the
chain of commits leading to any given point. If SHA-1 can be broken, it
can conceivably be used to modify the history of a repository in ways that
are difficult or impossible to detect.
Git has long included defenses against the known SHA-1 attacks, and few
people appear to be seriously worried about the potential for compromised
repositories now. Still, it makes a lot of sense to move to a more secure
hash function.