Git is one of the most popular version control systems, reliable and high-performance, providing flexible non-linear development tools based on branching and merging. To ensure history integrity and resistance to changes "retroactively", implicit hashing of all previous history is used in each commit, it is also possible to certify with digital signatures of individual tags and commits developers.
Recently its new version "Git 2.29.0" was announced and compared to the previous version, 627 changes were adopted in the new version, produced with the participation of 89 developers, of which 24 participated in the development for the first time.
Git 2.29.0 Key New Features
In this new version, includes an experimental option to use the SHA-256 hashing algorithm instead of the compromised SHA-1 when writing objects to the repository. The hash is generated from the content of each object in Git and is its unique identifier. Any change in the data or headers of an object leads to a change in its identifier. The occurrence of collisions in the hash algorithm theoretically does not exclude the formation of two different data sets with a resulting hash.
Unfortunately, the SHA-1 algorithm turned out not to be resistant to artificial collision formation, but to the commission of real attacks to the substitution of objects in Git by means of the manipulation of collisions SHA-1 improbable, since to annul a separated object it is necessary that the annulled object already contains a collision pattern, that is, an arbitrary block does not can be replaced.
Since each collision requires enormous computing resources, the already calculated templates are known which lead to collisions and earlier in Git a check was added for attempts to use them on objects.
At this stage of development, you can only choose between SHA-1 and SHA-256, but so far you cannot combine different hashes in a repository at the same time. Also, as of now, no Git provider, including GitHub, supports repositories with SHA-256 hashes. There are plans to add portability features in the future.
Another change in this new version is in the command "Git fetch" and "git push" to those who adds support for exclusive link specs (refspec), expands matching link rights between branches in local and external repositories. Excluding reference specs can be useful in situations where you need to not only select, but also exclude certain branches from the mapping. For example, when it was necessary to check all the "refs / heads / *" branches, except one "refs / heads / ref-to-exclude", first it was necessary to specify a complete list, explicitly including each branch.
New fields have been added to "git for-each-ref" which can be specified with the "-format" option, in addition to the name, type and id of the object. For example, the added fields content: size, subject: sanitize, and modifier: short to display short object identifiers. It is also allowed to specify multiple "–merged" and "–no-merged" arguments to filter links.
When a conflict occurs during a "git merge" operation, commit message header is now in brackets to more explicitly separate the commit data from the Git diagnostic messages.
Added a new setting "merge.renormalize", when set, check-out and check-in operations are performed for each stage of a three-way combination.
The second version of the Git communication protocol has been rolled back, which was disabled in version 2.27, and is used when a client connects remotely to a Git server. The bug that was causing stability issues has been diagnosed and fixed.
The "–first-parent" option has been added to the "git bisect" command, who is used to identify the revision in which a regressive change occurred, to change the selection of commits that pass between the known working review and the review in which the issue occurred. If you specify "–first-parent", only commits on the merged branch are counted, ignoring the merge commit itself.
Improved the efficiency of the internal command "git index-pack" Used when running "git push" or "git fetch" when parallelizing the packing of an index on multi-core systems.
Added the "merge.suppressDest" setting, which controls the addition of the phrase "in $ dest" to the "Merge $ upstream into $ dest" messages issued when branches are merged (previously, the phrase "in $ dest" it was not showing for the main branch by default).
Fixed a vulnerability in the backend "contrib / mw-to-git" (not built by default) to push and retrieve data from MediaWiki. The problem allowed to organize the execution of the code when accessing a MediaWiki instance that was under the control of an attacker.
Finally, if you want to know more about it, you can check the details In the following link.