Git 2.6, including flexible fsck and improved status
The open source Git project has just released Git 2.6.0. Here’s our take on its most useful new features: git fsck flexibility If you’re tired of having git fsck remind…
The open source Git project has just released Git 2.6.0. Here’s our take on its most useful new features:
git fsck
flexibility
If you’re tired of having git fsck
remind you of peccadillos from your distant past, read on. With Git 2.6, you can tell git fsck
not to be quite so picky about minor data errors in your project’s history.
The oddly-named1 git fsck
command verifies the integrity of a Git repository, checking both that its data has not been corrupted and that its objects have the right format. You can even enable Git’s transfer.fsckObjects
configuration variable to make Git apply the same checks to objects that are pushed into your repository. At GitHub, for example, we enable this feature on our servers to block malformed objects from entering your project’s history in the first place.
But what happens when you detect a problem in an object that is already part of your project’s history? You may recall that Git objects are content-addressed and immutable. Changing an object’s content, even to fix a syntactic error, changes its SHA-1 hash. And any commits which build on that object will need to update their references to it, changing their SHA-1 hashes, and so on.
Therefore, fixing a broken object requires all subsequent history to be rewritten. Sometimes it is worth doing. But sometimes, for mild forms of corruption in a repository that has already been cloned by many users, the repair process can be more trouble than it’s worth. Accepting the objects as they are can sometimes be the least bad solution. But until now, that meant turning off these fsck
checks entirely, losing all of the extra protection.
But now With Git v2.6, there is a better option. You can now adjust the severity of particular fsck
warnings, or even tell fsck
to ignore warnings entirely for a particular object. To demonstrate, let’s create two commit objects with broken email addresses:
$ git cat-file commit HEAD | sed 's/</<</' | git hash-object --stdin -w -t commit
2fae34b45b7202796fbe07fdb73d47ba94af1878
$ git cat-file commit HEAD^ | sed 's/</<</' | git hash-object --stdin -w -t commit
b4a1fc6eed23c19fd5eed3f17d50b2a155d56aa9
git fsck
rightly complains about the broken objects:
$ git fsck
error in commit 2fae34b45b7202796fbe07fdb73d47ba94af1878: badEmail: invalid author/committer line - bad email
error in commit b4a1fc6eed23c19fd5eed3f17d50b2a155d56aa9: badEmail: invalid author/committer line - bad email
Checking object directories: 100% (256/256), done.
If your history is riddled with invalid email addresses, you might decide to tell git fsck
to ignore this type of corruption in the whole repository:
$ git config fsck.badEmail ignore
$ git fsck
Checking object directories: 100% (256/256), done.
On the other hand, perhaps you only want to tolerate the existing broken objects, but you still want git fsck
to complain if any new ones enter your repository. If so, you can tell fsck
“don’t give these objects any trouble; they’re with me.”
$ git config fsck.skiplist "$PWD/.git/skiplist"
$ echo 2fae34b45b7202796fbe07fdb73d47ba94af1878 >>.git/skiplist
$ echo b4a1fc6eed23c19fd5eed3f17d50b2a155d56aa9 >>.git/skiplist
$ git fsck
Checking object directories: 100% (256/256), done.
Since Git objects are immutable, you know that the objects you have vouched for cannot develop new problems—unless of course the object’s data gets corrupted on disk, in which case fsck
will complain anyway, regardless of the skiplist.
git status
more informative during interactive rebase
If you’ve ever used Git’s interactive rebase on a large series of commits, you know that it’s easy to get confused about where you are. The git status
command used to report that you are rebasing, but not much more:
$ git status
rebase in progress; onto 1e7a542
You are currently editing a commit while rebasing branch 'master' on '1e7a542'.
nothing to commit, working directory clean
But as of v2.6, git status
gives much more context about your progress through the rebase:
$ git status
interactive rebase in progress; onto 1e7a542
Last commands done (5 commands done):
pick da6bc48 commit four
edit 12ee9f3 commit five
Next commands to do (5 remaining commands):
pick 8262b99 commit six
squash 0f9e8ec commit seven
You are currently editing a commit while rebasing branch 'master' on '1e7a542'.
nothing to commit, working directory clean
log --date
can use custom formats
Git’s --date
option (and the matching log.date
configuration variable) let you format commit dates in a variety of standard formats, including rfc2822
and iso8601
. But until now, you couldn’t invent your own formats. As of v2.6, Git supports the same formatting language as your system’s strftime(3)
function. This lets you do silly things:
$ git log --date=format:"On the %d day of %B, my true git gave to me..."
commit bee53d49e0899e697f72ea3cee87427f319f5707
Author: Jeff King <peff@peff.net>
Date: On the 05 day of April, my true git gave to me...
...a commit message in a pear tree.
But it also lets you take advantage of your system’s localized date code. For example, %c
shows the time in your preferred local format:
$ git config log.date "format:%c"
$ export LANG=es_ES.UTF-8
$ git log
commit bee53d49e0899e697f72ea3cee87427f319f5707
Author: Jeff King <peff@peff.net>
Date: dom 05 abr 2015 13:02:03 GMT
...a commit message in a pear tree
git log --cc
now shows diffs by default
The --cc
option (e.g., to git log
) modifies the way Git displays the diffs for merge commits. But until now it did not actually tell Git to show the diff. Now --cc
implies -p
, so that you don’t have to specify the latter option separately.
The rest of the iceberg
That’s just a peek at the improvements in Git v2.6. For the full list of changes, check out the release notes.
This Git release has 665 commits from 67 contributors. We’d especially like to shout out to Junio C Hamano, who recently celebrated his 10th year as Git’s maintainer. Thanks, everybody!
[1] The name isn’t so odd if you know the history. Unix systems have long had an fsck
command, which does a File System ChecK. The original idea of git was to act as a content-addressable filesystem for versioned data. Thus, its checking tool was naturally named git-fsck
.
Written by
Related posts
Code referencing now generally available in GitHub Copilot and with Microsoft Azure AI
Announcing the general availability of code referencing in GitHub Copilot and Microsoft Azure AI, allowing developers to permit code suggestions containing public code matches while receiving detailed information about the match.
The nuances and challenges of moderating a code collaboration platform
Sharing the latest data update to our Transparency Center alongside a new research article on what makes moderating a code collaboration platform unique.
GitHub Copilot now available in github.com for Copilot Individual and Copilot Business plans
With this public preview, we’re unlocking the context of your code and collaborators—and taking the next step in infusing AI into every developer’s workflow.