Skip to content

Latest commit

 

History

History
253 lines (217 loc) · 15 KB

2022-06-30-edition-88.markdown

File metadata and controls

253 lines (217 loc) · 15 KB
title layout date author categories navbar
Git Rev News Edition 88 (June 30th, 2022)
default
2022-06-30 12:06:51 +0100
chriscool
news
false

Git Rev News: Edition 88 (June 30th, 2022)

Welcome to the 88th 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 months of May and June 2022.

Discussions

General

Support

  • Bug in merge-ort (rename detection can have collisions?)

    Glen Choo reported on the mailing list that git merge was failing on certain branches of a repo used at his workplace. As the repo is a public one, Glen was able to share the full recipe to reproduce the bug.

    When following it, this error appears:

    Assertion failed: (ci->filemask == 2 || ci->filemask == 4), function apply_directory_rename_modifications, file merge-ort.c, line 2410.

    Glen noticed that the bug seemed to be specific to the "ort" merge strategy, which became the default merge strategy in Git 2.34.0 released last November. When using the "recursive" strategy, which used to be the default merge strategy before "ort" took over, the merge seemed to work as expected.

    Glen also tried to debug the issue by himself and found that the reason for the assertion failure seemed to be that two files involved in the merge were renames of each other.

    Elijah Newren, who developed the new "ort" strategy, thanked Glen for the detailed report, and said that he found a small reproduction recipe to simplify what's going on. He explained it with the following sequence:

#   Commit O: sub1/file,                 sub2/other
#   Commit A: sub3/file,                 sub2/{other, new_add_add_file_1}
#   Commit B: sub1/{file, newfile}, sub1/sub2/{other, new_add_add_file_2}
#
#   In words:
#     A: sub1/ -> sub3/, add sub2/new_add_add_file_1
#     B: sub2/ -> sub1/sub2, add sub1/newfile, add sub1/sub2/new_add_add_file_2

He noted, though, that he can also trigger a different fatal error in the "ort" strategy with a small tweak to the test setup, and can also trigger that same other fatal error in the "recursive" strategy with his test cases.

He then explained that both the "ort" and "recursive" merge strategies have code to avoid "doubly transitive [directory] renames". Such renames happen when, for example, on one side of the merge a directory named "A" is renamed to "B", while on the other side "B" is renamed to "C".

However, the code to avoid "doubly transitive [directory] renames" is fooled when a parent directory of a directory is renamed. For example if on one side a directory named "A" is renamed to "B", while on the other side a leading directory of "B" is renamed to "C". That still wouldn't be quite enough to trigger this bug, though. It also requires adding a file into directory A on one side and a file with the same name into directory B on the other.

Junio Hamano, the Git maintainer, thanked Elijah for his continued support of the merge strategy, and noticed that at least the code was not "making a silent mismerge" in this special case, and that the recursive strategy could be used as a fallback.

Elijah replied that he was glad the recursive strategy worked for Glen but noted that it didn't work with his minimal reproduction test case, which suggests it's less reliable as a fallback than one might hope.

Glen then wondered if turning off rename detection could help in case of merges with complex renames like this, but Elijah pointed out that might be more problematic than helpful, particularly since this case had a very large number of renames and users tend to have difficulty correctly resolving the conflicts that result from a lack of rename detection. However, he suggested that if turning off rename detection was really wanted that one could use the "resolve" strategy instead, which "is roughly the recursive strategy minus the renames and the multiple merge base handling".

Elijah also posted a small patch series that adds test cases demonstrating the bug Glen found and the related ones he found based on it, and fixes the bugs in the ort strategy. (The recursive strategy is deprecated, and the bugs noted here are not security critical.)

Jonathan Tan reviewed the series and verified that it indeed fixes Glen's test case. Calvin Wan also commented on the patch series. So there is good hope that after a few iterations to polish the series the bugs will be fixed soon.

Releases

Other News

Events

  • Git Merge 2022 by Lee Reilly on GitHub blog. Git Merge, the conference dedicated to bringing the Git community together, returns on September 14-15 in Chicago, Illinois, USA. Call for Speakers is open through Sunday, July 10.

Various

Light reading

Git tools and sites

  • Sourceware is community run infrastructure, mailing lists, git, bug trackers, wikis, etc. hosted in the Red Hat Open Source Community Infrastructure Community Cage. Uses shared buildbot for (test) automation, and patchwork for tracking the state of contributions; most tests upload all results to bunsendb. Uses mirror at SourceHut, https://sr.ht/~sourceware/, for web forge.
  • unix-history-repo is a repository representing a reconstructed version of the Unix history from 1970 until today, based on the currently available data. Note that this repository will be often automatically regenerated from scratch.
  • git-repair can repair various forms of damage to Git repositories; a complement to git fsck, which finds problems, but does not fix them. It is a Haskell program, developed as a spinoff of git-annex (for large files management).
  • Rich Enhanced Shell History (resh) provides contextual shell history for zsh and bash, where relevant results are based on current directory, git repo, exit status, and host.

Credits

This edition of Git Rev News was curated by Christian Couder <[email protected]>, Jakub Narębski <[email protected]>, Markus Jansen <[email protected]> and Kaartic Sivaraam <[email protected]> with help from Bruno Brito, Elijah Newren, Matheus Tavares and Johannes Schindelin.