Git Rev News: Edition 41 (July 18th, 2018)
Welcome to the 41st edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on git.github.io.
This edition covers what happened during the month of June 2018.
Brian Carlson, who has been working for a long time on improving Git code to make it easier to support replacing SHA-1 with a new hash function, recently posted an update and invited people to discuss the future steps in this area.
As the new hash function is still undecided (see below), it is called “NewHash” by everyone for now. It is expected though that it will be a 256-bit hash algorithm while SHA-1 is 160-bit, and this change alone has required a lot of internal work.
With Brian’s latest patches Git would work using NewHash, including passing the test suite, though it would be incompatible with current Git.
As the hash function transition plan tells that a Git using NewHash should be able to communicate through fetching and pushing with a Git using SHA-1, the next step is to implement such kind of communication and that’s what Brian started to do.
Technically the work consists in porting everything to use a variable
the_hash_algo that will store information about the current
After describing other technical details related to his work and recommending ways to make current developments compatible with it, Brian suggested resuming the discussion about what NewHash should actually be, as he will need to actually use a new hash when writing objects to disk.
Brian then proposed to send to the list an analysis he made on “availability of implementations, performance, and other attributes described in the transition plan”.
Ævar Arnfjörð Bjarmason, Jonathan Nieder and Duy Nguyen all replied separately to Brian to congratulate him for his work, to discuss a few technical details, and to welcome his analysis of the possible hash functions.
Brian replied to them by sending his Hash algorithm analysis to the mailing list. The conclusion from this document is that the best is one of SHA-256, SHA-3-256 and BLAKE2b depending on the goals (security, performance, availability).
Jonathan replied to this analysis by asking technical questions and summarizing the previous discussions. He said that Yves Orton and Linus Torvalds prefer SHA-3 over SHA-2 because of how it is constructed, though a number of knowledgeable people suggested K12 instead of SHA-3 for performance reasons, while Johannes Schindelin, alias Dscho, strongly prefers SHA-256 because it is well known, widely available and fast.
Linus replied to this summary by explaining that “SHA-2 has the exact same weak inter-block state attack” as SHA-1, and it would be crazy to “go with a crypto choice that has that known weakness”. About performance he thinks that “‘256-bit hashes are bigger’ is going to be the more noticeable performance issue” and that K12 “should be a front-runner” as it was suggested by the Keccak people.
There were further discussions involving Ævar, Linus, David Lang, Brian, Dscho and also Gilles Van Assche who co-created Keccak which then became SHA-3, but there was still no consensus and no decision has been made.
- Git v2.18.0
- Git for Windows 2.18.0
- libgit2 v0.27.3
- Bitbucket Server v5.12
- GitHub Enterprise v2.14.0, v2.13.6, v2.12.14, v2.11.20, v2.13.5, v2.12.13, v2.11.19
- GitLab 11.0.3, 11.0.2, 11.0.1, 10.8.5, 10.7.6, 11.0.0
- GitKraken v3.6.6, v3.6.4
- GitHub Desktop v1.2.6, v1.2.5, v1.2.4
- Gerrit Code Review v2.14.10
- Git Tower GUI v2: Better than Ever: The New Tower Has Launched, now with annual license model
A Git standup on IRC every two weeks at 17:00-17:30 UTC has been announced by Jonathan Nieder.
Derrick Stolee has written about Commit Graph on Microsoft DevOps Blog:
Echoes of Microsoft acquring GitHub (see Git RevNews Edition #40)
- Gentoo GitHub Organization hacking incident summary
- GitLab Moves to Automate DevOps by Mike Vizard on DevOps.com
- The advantages of an email-driven git workflow by Drew DeVault
- Git Syncing tutorial from Atlassian
- Version Control Before Git with CVS on Two-Bit History blog (though it missed the problem with repeated merges in CVS)
- The 5 basic Git commands every beginner needs to master by Cameron McKenzie
- How to git revert a commit: A simple undo changes example by Cameron McKenzie
- How to reset, revert, and return to previous states in Git by Brent Laster
- Terrible Ideas in Git by Corey Quinn (tongue-in-cheek?), with some good Git tips
- The Git Rebase Introduction I Wish I’d Had by Max Antonucci (2017)
- Anatomy of a perfect pull request by Hugo Dias
- Meet the GitLab Web IDE on GitLab Blog
- Storing Encrypted Credentials in Git by Bozhidar Bozhanov, with a look at a possible solution;
see also Best practices for securely storing API keys by Bruno Pedro (mentioned in Git Rev News Edition #39)
Git tools and sites
- GitRuler - Automated checking of the status of a repository, like unit testing for a git repo (that repo has specific state)
- diffoscope: in-depth comparison of files, archives, and directories (will recursively unpack archives of many kinds and transform various binary formats into more human readable form)
- gitfiti is a tool for crafting graffiti in a GitHub commit history calendar; includes list of notable derivatives
- GitLab Pages: websites for your GitLab projects, user account or group
- A new archive of linux-kernel mailing list (LKML) posts going back to 1998 is now available at lore.kernel.org, which is based on public-inbox (with Git-backed archival mechanism you can clone and pull)
This edition of Git Rev News was curated by Christian Couder <firstname.lastname@example.org>, Jakub Narębski <email@example.com>, Markus Jansen <firstname.lastname@example.org> and Gabriel Alcaras <email@example.com> with help from Luca Milanesio and Derrick Stolee.