Welcome to the 108th 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 January and February 2024.
[Bug?] “git diff --no-rename A B
”
Junio Hamano, the Git maintainer, sent an email to the mailing list
saying that when git diff
was used with --no-rename
instead of
--no-renames
, rename detection was still performed. He
wondered if that was a bug, because either --no-rename
should be
interpreted as being a shortened form of --no-renames
, which is
a valid option
and should disable rename detection, or --no-rename
should be
rejected with an error message and termination of git diff
.
Dragan Simic replied to Junio that indeed, in case the option is not recognized, an error message should be emitted.
Jeff King, alias Peff, also replied to Junio saying he tried
--no-foo
, which properly errored out. He then wondered if it could
be a bug in the parse-options
code that could be confused because
git diff
has both --[no-]rename-empty
and --no-renames
. As
there is an abbreviation ambiguity between --no-rename-empty
and
--no-renames
when --no-rename
is used, the parse-options
code
should not allow such an abbreviation and should error out.
He suggested, as an alternative to fixing the bug, that a new
--renames
option could be introduced. It would be synonymous to
--find-renames
, which is currently the only opposite to
--no-renames
. He proposed a patch to do that and showed that after
his patch, --no-rename
would properly error out.
René Scharfe replied to Peff that the issue came from a patch
written in 2019 that disabled abbreviated options when there could
be an ambiguity. The code handling abbreviations would trigger not
only if the condition guarding it was satisfied, but also if it was
reached through a goto
statement. The patch disabling abbreviated
options only took care of the condition guarding that code, but not of
the goto
statement. Along with these explanations, René provided a
patch fixing the bug.
Junio thanked René for spotting the “nasty” bug and said he agreed that the code was confusing.
René replied to Junio with a follow-up patch removing the
goto
statement.
Peff also replied to René’s first patch wondering if it fixed all the possible issues, but then in a reply to himself agreed that René’s patch was indeed fixing all the issues discussed.
Junio later merged both of René’s patches, and they were part of the recently released Git versions 2.43.2, 2.43.3 and 2.44.0.
Bonus reading: “A Case against the GO TO Statement” by Edsger W. Dijkstra
Various
Light reading
-L
),
git blame with following, word diff, resolution reuse (git rerere
).--sort
, --column
), safe force-pushing (--force-with-lease
),
SSH commit signing, push signing, git maintenance
.git commit --fixup
and rebase.autosquash
.Easy watching
Git tools and sites
git-q
.This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Jakub Narębski <jnareb@gmail.com>, Markus Jansen <mja@jansen-preisler.de> and Kaartic Sivaraam <kaartic.sivaraam@gmail.com> with help from Brooke Kuhlmann, Jack Lot, Štěpán Němec and Bruno Brito.