Git 2.17 Improves Moved Code Diffs and Object Search

Git latest release, version 2.17, brings a multiplicity of improvements and minor new features, including better moved code coloring, finding objects in history, and more.

Git 2.17 improves diff display by coloring groups of moved lines. Traditionally Git showed moved lines of code just like any other code changes. Now, using the --color-moved option you can see lines that were moved and not changes in a different color than lines that were moved and changed. The color used for moved lines can be specified using the diff.colorMoved configuration setting. The --color-moved option supports the following modes:

• no: Moved lines are not highlighted.
• zebra: Git detects blocks of at least 20 alphanumeric characters and colors them alternatively. The change between two colors indicates that a new block was detected. The colors used to paint two blocks are specified using the color.diff.{old,new}Moved or color.diff.{old,new}MovedAlternative settings.
• dimmed_zebra: Similar to zebra with uninteresting parts of moved code dimmed.
• plain: Uses color.diff.newMoved for lines that were added in one location and removed in another, and color.diff.oldMoved for lines that were removed but added somewhere else.

The new --find-object option accepted by the log and diff commands is able to limit its findings only to commits referring to a given object hash. A Git object may appear in multiple commits, such as when an object is first created in a commit, then deleted in another, and it may also corresponds to multiple paths if it has been renamed or copied, so it is not easy to track down. Now, for example, the following command will select and display all commits referring to the specified object:

git log --find-object=<hash-here> -p

Both git rebase and git am support a new --show-current-patch option that displays the diff being applied by the command. This can be useful when rebasing or merging stops with a conflict. Additionally, the merge command has slightly modified its “no fast forward by default” policy. Now, when merging a tag, fast forward is applied except when the tag object does not sit at its usual place in the /refs/tags hierarchy. This should prevent unnecessary merge commits when downstream contributors update their topic branches with tagged released from the upstream.

Git 2.17 includes far more changes that can be reviewed here, so do not miss the official release notes.