"In 2.9, Git's diff engine learned a new heuristic: it tries to keep hunk boundaries at blank lines, shifting the hunk "up" whenever the bottom of the hunk matches the bottom of the preceding context, until we hit a blank line. "

I like the new diff improvements

I don't understand why Git can't just make the [histogram algorithm][1] default, which has better performance than the base Myers algorithm, and is already built to integrate this type of heuristics (without the bugs that caused this patch to get held back).

[1]: http://stackoverflow.com/questions/32365271/whats-the-differ...

In a few (relatively) short years, git's diff has improved on all the other diffs out there.

I didnt even know about the mentioned diff-script: https://github.com/git/git/blob/master/contrib/diff-highligh... It gives pretty nice output :-)

I should definitely learn more about extending git!

There's also this https://github.com/so-fancy/diff-so-fancy

+1 for this. I started using it a few months ago for all my git diffs and I quite like the output. The biggest thing for me is being able to easily see partial line changes.

Requires Node though. Not sure that many people have that installed.

It does not:

> For convenience, the recommended installation is via NPM. If you'd prefer, you may choose to do a manual installation instead. (highlighting by me)

It is written in Perl.

Wait, what? A perl app distributed through NPM? What's next, a node app on CPAN?

Color me perplexed.

There are a lot of non-JS packages in NPM. The Closure compiler, for example.

My favorite git diff extension is the side-by-side diff by cdiff:

https://pypi.python.org/pypi/cdiff

It also features word-level change highlights and other common flares.

I still prefer Araxis.

http://www.araxis.com/merge/index.en

I use: http://www.kaleidoscopeapp.com/

It's the absolute best, been using it for years.

Beyond Compare is the best I've found (especially for complex merges): http://www.scootersoftware.com/

Me too. I tried ataxia for about 6 months and hated it, got told about beyond compare, paid for a license after only a few days of the trial .

Beyond Compare is great. I prefer Araxis. I think most people would be very happy with one of the two. Whichever you happen to prefer.

Cool. BitKeeper internal diff, used for recording history and displaying changes has done this since 2001. https://gist.github.com/wscott/c403526ca19a210c13ad649136c15...

http://bkbits.net/u/bk/bugfix/?PAGE=patch&REV=3bdee65dgEb_uM...

Does anyone know if this only works when displaying diffs, or when generating them? It'd definitely be nice if diffs were more readable when sent to mailing lists, i.e. from git format-patch.

I'm fairly sure this applies only to the generating engine. (Otherwise it'd somehow need to reformat old diffs on the fly.)

Reformat old diffs? If you're under the impression that Git stores diffs you're mistaken. It stores the full file contents and delta-compresses them later.

Diffs in Git are purely a presentation format for human consumption.

> Diffs in Git are purely a presentation format for human consumption.

git format-patch says hi. Obviously the diff engine changes won't apply to already generated text diffs.

You can pipe an existing diff through diff-so-fancy or diff-highlight:

    cat foo.diff | diff-so-fancy

I've never tried, but that's what the doc says.

[time passes]

Oh yes, it seems to work. It doesn't do colors when I try it, but that's probably a misconfiguration on my side. It's how this is intended to be used.

Does anybody know if the new diff heuristic engine takes info from a .gitattributes file in to account? When using git diff to view changes it already makes a difference, see http://urbanautomaton.com/blog/2011/07/28/git-grep-and-langu...

Bitbucket[1] also mentions a few other new cool stuff in 2.9, like making the `--verbose` flag to `git commit` default:

    git config −−global commit.verbose true

[1] https://blog.bitbucket.org/2016/06/13/git-2-9/

Maybe I'm missing something, but that link doesn't say commit.verbose is true by default, it just documents the new setting you can set.

by default it is false. but commit.verbose is introduced by git 2.9. setting it before 2.9 didn't have any effect.

Hidden at the end of the changelog is the addition of the the new config entry: "core.hooksPath" which lets you specify globally or per repository where hooks should point to.

In the Git-hooks project we have been using the init.templatedir which this replaces (as it is better), but for those that can't upgrade to 2.9 you can use init.templatedir and some variation of what Git-Hooks does to obtain similar results.

https://github.com/icefox/git-hooks/blob/master/git-hooks#L1...

Sweet. I implemented that feature vaguely fearing that nobody except me was going to use it, in my case to ease setting up "auditing" hooks on a centralized Git server. Awesome that you find in useful.

Oh man, excellent. I've wanted this feature in my [Plushu][] project for years: this will make my code significantly simpler.

[Plushu]: http://comments.gmane.org/gmane.comp.version-control.git/253...

The new "rebase -x" seems really useful. It runs a test script on all patches in the history, making it useful for getting a bunch of patches tested for merging at once.

This makes it easier to not have broken commits (e.g. ones that don't build) in master, which in turn makes git bisect more useful.

Can someone say how this differs from 'git rebase -i --exec' ?

It doesn't. It's just more convenient to use, and we took the opportunity to make people aware of the existing `--exec` feature.

It can be non-interactive now. Think "git rebase master"

git rebate... I wonder if there's also git refund, git coupon and git discount?

Sigh. Why can't all autocorrects handle git verbs?

OT

The new diff script (https://github.com/git/git/blob/master/contrib/diff-highligh...) is juicy indeed.

It is written in Perl. The Perl interpreter is available on most UNIX systems, so that's handy. I wonder if there is any Lisp-like language that is as common, that you can write scripts and expect them to run on most systems. Would be nice since Lisp languages have very few concepts to learn...

I hope to one day push the highlighting inside of git itself. That should make it more efficient, and we can do a true LCS diff to find the common parts, rather than the front/back heuristic it currently does (see the diff-highlight README for the gory details).

It's just a little complicated because of the way it interacts with existing internal diff features (in particular the whitespace-error highlighting).

Guile may be the closest, but it failed to gain much traction despite support in some popular GNU tools like GDB. It's certainly not installed on most systems, but it at least has a tiny chance of being present.

On Arch Linux it's a dependency of both gdb and make, but it seems that other distributions go out of their way to avoid shipping it (Debian e.g. builds gdb without a hard dependency on it, and you need to install a separate make-guile package to get guile-enabled make).

Is guile part of the default packages on any unix-alike distribution though?

The huge upside of perl is not necessarily that it's available, but that it's available by default.

Even more OT, but: This script is not new at all: https://github.com/git/git/commits/master/contrib/diff-highl...

I second the ability to use a Lisp language for this also (Racket Please).

'git' is the name of the command line interface. the VCS is technically called "git's monster"

You're joking, right?

I'm not sure how anyone could find version control funny.

yes, it's one humor joke

What is the algorithm of heuristics diff? Is it comparing longest-match?

    So, if i originally have
    x
    b
    n
    then adding x a n on top of it, it will become
    x
    a
    n
    x
    b
    n

How can i know that i add x-a-n? Basically, isn't it comparing x-b-n and detect it has changes on 'b' block, so the 'b' block become a-n-x-b?

Edit: My bad, didn't see this https://news.ycombinator.com/item?id=11915351. It has been explained there.

> Faster and more flexible submodules

I have a big, monolithic repository which I'm looking to break up in a migration to Git.

If I run;

    git submodule split -P <path_to_sm> -b <name_of_branch> --jobs=4

Will I see the same improvements, as documented?

> I have a big, monolithic repository which I'm looking to break up in a migration to Git.

Why?

Not the OP, but if it is big enough, common tasks such as 'git status' can take seconds to complete, which is annoying.

That said, I won't be using git submodules again on another project, it was a bit cumbersome for my taste.

I haven't been following releases for a while, it's nice to see that submodules can now (2.8) be actually used.

Just curious, were there any changes to sparse-checkout? It had abysmal performance in pre-2.x if you threw more elaborate paths at it, or more paths in general.

We've been using submodules for almost a decade. It's easy to make mistakes, which is bad, but they're hardly unusable.

Well, I might overstated how slow it was to check them out in serial. They are still PITA thanks to specific behavior, missing features (both in git and in 3rd party tools such as bitbucket), etc..

The benefits oftentimes overshadow the issues with them, but there are drawbacks to using them.

Are they planning to simplify standard day to day command from flag nightmare to something that mortal can actually remember?

What flags do you have particular problems with and what could you see as a replacement for them?

Is there already a pre-built package for MacOSX?

https://www.kernel.org/pub/software/scm/git/git-2.9.0.tar.xz (as used by homebrew)

Homebrew has it.

I sadly usually wait for the official AppleGit Xcode tools release for the Keychain integration I'm so sadly dependent on.

The 2.9 git install from homebrew prompted me for keychain access and then just "worked", this morning. My first time using brew git. So you may want to give it a whirl.

I'm not exactly sure what your use case is, but would this help? https://help.github.com/articles/caching-your-github-passwor...

I use brew'd git alongside git credential-osxkeychain.

Oh I should compare the new coloring with DiffSoFancy. I think DiffSoFancy still wins!

Over/under until git supports emoji in commit messages?

Why would it need dedicated support for it? It's already unicode aware.

I've put emoji in commit messages. Git already supports Unicode (mostly). Just make sure you're using a Unicode-aware terminal.

Great release. Submodules are bad practice riddled with problems, I think it wouldn't be bad to remove this feature at all, that way no-one will be have an option to use it.

I use submodules and they work fine. What is so bad about them that I shouldn't be using them?

Here's some good posts about submodules and alternatives, so you can make up your own mind:

http://blogs.atlassian.com/2013/05/alternatives-to-git-submo...

https://codingkilledthecat.wordpress.com/2012/04/28/why-your...

From what I've gathered skimming the numerous blog posts venting about submodules, it seems that people have trouble with submodules because they are trying to integrate them into a workflow they work poorly in (i.e., rapidly changing modules). There seems to be room for improvement for that type of usage, given what people are saying, but I wonder if there have been any changes to submodules since those posts (many of them are dated around 2011-2012).

My own positive experience with submodules involves dependencies that only occasionally change; I can always point to a specific tag that should be used.

Yes.

One should avoid to extract a component from the repo as a submodule too early, i.e when the interface of the component is not mostly stabilized.

If each commit in your "main" module is paired with a commit in your submodules, then you might be missing the point of module separation.

Even if the interface is stabilized, when you update implementation of a submodule you will still have to recursively update all submodules from main down to the changed module.

How do you point to a specific tag? Do you set branch : (tag)?

I've used submodules in multiple projects and haven't had any problems beyond standard git annoyances.

How do you share code between projects/teams then? How do you work on several branches simultaneously, each of them requiring a different version of their dependencies?

How do you handle submodules having the same version of their dependencies (diamond dependencies)? You will get tons of, not just redundant, but also conflicting duplicates. In many environments include dirs and such dont follow the file system hierarchy.

Git is not a package manager, don't make the mistake of trying to use it as one.