Git 2.17 Improves Moved Code Diffs and Object Search

| by Sergio De Simone Follow 17 Followers on Apr 13, 2018. Estimated reading time: 2 minutes |

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.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you