Welcome to the 22nd 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 month of November 2016.
Eight days before the v2.11.0 Git release, Robert Dailey asked on the mailing list if there would be a new diff heuristic in the new release:
I dug into the git diff documentation here:
https://git-scm.com/docs/git-diff
It mentions a “–compaction-heuristic” option. Is this the new heuristic outlined by the release notes? If not, which is it? Is the compaction heuristic compatible with the histogram diff algorithm? Is there a config option to turn this on all the time? For that matter, is this something I can keep on all the time or is it only useful in certain situations?
There’s still so much more about this feature I would like to know.
Stefan Beller answered most of Robert’s questions saying that indeed the “–compaction-heuristic” option is the new heuristic, and it is compatible with the histogram diff algorithm “as the compaction heuristic is applied after the actual diff is performed”.
Stefan also said that ‘diff.compactionHeuristic’ is the config option to turn this heuristic on and that “the background story (and what this new compaction heuristic is doing) is found at Michael Haggerty’s diff-slider-tools repository”.
But Jeff King, alias Peff, who works with Michael for GitHub, replied that the above ‘compaction heuristic’ is about “the ‘old’ attempt at a similar feature from v2.9. The ‘new’ one goes by the name ‘–indent-heuristic’ (and ‘diff.indentHeuristic’ in the config)”.
Peff added that “more discussion about how it works” can be found in the commit message of Michael’s commit that introduces the ‘indent heuristic’.
This commit message indeed looks impressive and shows that a lot of work has been going on for a long time to improve the diff heuristics. It can make one wonder if Git developers are soon going to use artificial intelligence algorithms to train a neural network to yield the best possible diffs.
Anyway Jacob Keller also answered saying that the config option is undocumented and that:
Currently it is being evaluated and likely we want to make it default in the near future once we are certain that it helps and doesn’t make any difference worse.
So long term you will not need any special knobs to benefit.
Peff agreed that “it is not the default in v2.11, but it probably will become so in a future version”.
Later in the GitHub blog post about the v2.11 release, Peff mentioned this new (undocumented but testable) feature.
It’s interesting to see that users are interested in better diff algorithms, and that Git developers provide them with new advanced options to play with before hopefully improving the default algorithms.
Dun Peal wrote that he is using vimdiff as his mergetool, and has the ‘mergetool.vimdiff.trustExitCode’ configuration option set to ‘true’ in his ~/.gitconfig file. Nevertheless when he makes vimdiff exit with code 1 (to mean failure), Git still acts as if the merge had succeeded.
From the documentation of ‘mergetool.vimdiff.trustExitCode’ he expected that with such an exit code Git would consider that the merge hadn’t been successful.
Jeff King, alias Peff, replied that the configuration variable “is used only for a ‘user’ tool, not for the builtin tool profiles”. And, while vimdiff has a builtin tool profile, Peff suggested a workaround that configured vimdiff as a user tool.
Dun then wrote that he would find more sensible that by default Git would rely on the exit code from the tool, and that he hopes the developers change this default, or at least let users override it for the builtin invocations.
Peff replied:
Yeah, I’m inclined to agree. But like I said, I’m not too familiar with this area, so maybe there are subtle things I’m missing.
Junio Hamano later explained that “some tools are known to give unusable exit codes, so we ignore their exit codes by default”.
As Peff had said that he doesn’t use mergetools, Dun also asked:
Finally, if you’re not using mergetools, how do you resolve conflicts?
Peff replied that he just edits the conflicted sections in vim and uses git-jump.
In the meantime, David Aguilar, who has previously contributed a lot to mergetool, sent a patch to allow “tools to opt-in to trustExitCode=true”. He warned though that for tkdiff and kdiff3, his patch has “a subtle change in behavior, but not one that should be problematic”.
Later, David sent another patch that “allow tools to advertise their own default value for trustExitCode, so that users do not need to opt-in to the original behavior”.
Peff and Junio reviewed the patches and found them mostly good, though they suggested some small improvements.
David has since posted new patches that have been found “sensible”, so it looks very likely that this area of Git will improve in the next feature version.
Who are you and what do you do?
I’m a software developer living in Los Angeles, CA. I work at Walt Disney Animation Studios where I develop tools that are used for creating computer-generated animated films.
WDAS is a Linux shop. When I started there in 2004 we were using an SCM system that was slow and not too easy to use, so there was a desire to find a better solution. Git started to gain momentum just as we were looking to reimagine our development workflow, so I took a bet on Git.
We started migrating the studio’s software teams to Git in 2008, and I soon became the person you’d find in git.txt as described in xkcd/1597.
What would you name your most important contribution to Git?
Within the Git project itself, my most important contributions are the addition of “git difftool” and on-going maintenance of its sibling “git mergetool” merge-resolution helper tool.
git difftool is a natural extension of Git’s rich diff capabilities.
difftool was created when a co-worker suggested that Git needed better
tools for inspecting changes, and that they preferred visual tools such
as tkdiff and xxdiff. I had hacked together a script that we were using
daily at work, so I
shared it
with the mailing list. Folks almost immediately started suggesting
improvements. git difftool matured in contrib/ for a few months and
became part of Git’s core toolset in v1.6.3.
What are you doing on the Git project these days, and why?
I still help maintain and review code related to difftool and mergetool. When users report issues I always try to distill the problem down into a testcase, add it to Git’s test suite, and come up with a patch to fix the problem.
Outside of the Git project, but still within the Git community, I wrote and continue to maintain Git Cola, a free and cross-platform graphical user interface for Git that was designed around my unix-centric, keyboard-focused user interface sensibilities. I still improve and add new features to Git Cola when time permits.
Git has helped me immensely in my daily workflow so I think it’s important to contribute back in any way I can.
If you could get a team of expert developers to work full time on something in Git for a full year, what would it be?
I would like to see a focus on scalability and better support for working with large files and repositories. There are existing projects in this area that would benefit from help:
If you could remove something from Git without worrying about backwards compatibility, what would it be?
From a usability angle, git reset --{soft,mixed,merge,keep,hard}
is a lot to understand for beginners.
I always thought it would be good for Git to fully adopt the “staging area” metaphor instead of its traditional “index” and “cache” jargon, but I would not go so far as to remove support for old flags. At most, I’d stop advertising them in the documentation, but would still support them. Backwards compatibility is a big deal in Git.
Lower hanging fruit:
What is your favorite Git-related tool/library, outside of Git itself?
Git Cola ;-)
A few more of my favorites are,
Various
Light reading
Git tools and sites
This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Thomas Ferris Nicolaisen <tfnico@gmail.com>, Jakub Narębski <jnareb@gmail.com> and Markus Jansen <mja@jansen-preisler.de> with help from David Aguilar.