This weeks git tip is going to be really short: I want to show you a way in which git is constantly improving.

Lets say I have the following angular class:

import { Component, Input } from '@angular/core';

@Component({...})
export class CounterComponent {
  @Input()
  count: number = 0;

  increment() {
    this.count++;
  }

  decrement() {
    this.count--;
  }
}

Now, if I want to add another @Input which makes the file now look like this:

<...>
export class CounterComponent {
  @Input()
  maximum: number = 9000;

  @Input()
  count: number = 0;

  increment() {
<...>

Up until git 2.14, calling git diff counter.ts would give us the following diff:

 @Component({...})
 export class CounterComponent {
   @Input()
+  maximum: number = 9000;
+
+  @Input()
   count: number = 0;

   increment() {

As you can see this looks a bit weird. When we think about the change that we made, we would argue that we added the upper @Input block instead of changing the variable assignment and then adding another @Input. The expected output would be this:

 @Component({...})
 export class CounterComponent {
+  @Input()
+  maximum: number = 9000;
+
   @Input()
   count: number = 0;

If you try this on your machine, this is probably the output that you are going to see. This is thanks to the so called indent heuristic. Git’s man page describes this heuristic like this: shift diff hunk boundaries to make patches easier to read. What this essentially does is it tries a couple of different ways to create the diff and then checks if the blocks in the diff have leading or trailing new lines. This is considered to be easier to read than having those newlines in the middle of the blocks. It assigns a score to each diff and then picks the one where the newlines (you could also say the indents) line up the best. You can see how this small heuristic improves the readability of the diff above. Conveniently for us, this feature was turned on by default in git 2.14.

You can still get the old output with --no-indent-heuristic but you probably will never want to do this. I think this is a nice example for how a small change in git can make your diffs look a bit nicer and take some potential confusion from your day to day work with git. Which I think is pretty cool.