"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 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 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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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 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.
I like the new diff improvements