
Git 2.9 released - bootload
https://github.com/blog/2188-git-2-9-has-been-released
======
neogenix
"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

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

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

I should definitely learn more about extending git!

~~~
Spiritus
There's also this [https://github.com/so-fancy/diff-so-
fancy](https://github.com/so-fancy/diff-so-fancy)

~~~
0942v8653
Requires Node though. Not sure that many people have that installed.

~~~
TimWolla
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.

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

Color me perplexed.

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

------
Spiritus
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/](https://blog.bitbucket.org/2016/06/13/git-2-9/)

~~~
comfydragon
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.

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

------
icefox
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...](https://github.com/icefox/git-hooks/blob/master/git-hooks#L165)

~~~
avar
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.

------
exDM69
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.

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

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

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

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

------
hkjgkjy
OT

The new diff script ([https://github.com/git/git/blob/master/contrib/diff-
highligh...](https://github.com/git/git/blob/master/contrib/diff-
highlight/diff-highlight)) 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...

~~~
tveita
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.

~~~
creshal
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).

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

~~~
marvy
You're joking, right?

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

------
fidz
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](https://news.ycombinator.com/item?id=11915351).
It has been explained there.

------
mr_sturd
> 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?

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

Why?

~~~
ansible
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.

------
rplnt
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.

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

~~~
rplnt
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.

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

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

------
nilsjuenemann
Is there already a pre-built package for MacOSX?

~~~
throwaway745234
Homebrew has it.

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

~~~
modoc
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.

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

------
rco8786
Over/under until git supports emoji in commit messages?

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

------
desireco42
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.

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

~~~
ithkuil
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...](http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-
git-subtree/)

[https://codingkilledthecat.wordpress.com/2012/04/28/why-
your...](https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-
shouldnt-use-git-submodules/)

~~~
riscy
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.

~~~
Ace17
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.

~~~
Too
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.

