Git 2.11 has been released

That piqued my curiousity, and I had to dig up the relevant commit: https://github.com/git/git/commit/bb84735c80.

It deals with wrapping an integer index around after incrementing it, the old code just used ++index and a bitmask, the new code uses + 1 and modulo.

I have problems understanding this right now, in my world ++index for an int really shouldn't trigger overflow when counting to at most 4, on any (sem-)realistic environment?

Feeling extra dense, must have more coffee.

The counter never resets, it just keeps going up and we only look at the low bits. So eventually it will need to wrap. It's doubtful that ever happened in practice, even on a 32-bit system (you'd need to print 2 billion SHA-1s in a single process, and even the largest repos have on the order of millions).

So the key difference between the old and the new is that the counter resets to zero every fourth call.

Jesus christ Git's interface design is horrible.

  Master Coder: Hmm. We refer to changes by a long, totally non-human-parseable string of characters that nobody can memorize,
  and when we abbreviate it, it doesn't work 100% of the time. What can we do about it?
  
  Novice Apprentice: Well... how about we stop using a long totally non-human-parseable string of characters that no 
  human can can memorize just to briefly refer to specific changes in human-readable output?
  
  MC: What?! HERESY. Making a human use a cryptographic hash to reference a single random logical reference point in a mass of
  logical binary objects among millions of others is clearly the best way to go. We just need some quick fixes.
  
  NA: But... you can't reference it via speech, it doesn't work reliably via text when abbreviated, and it gives absolutely no
  context whatsoever as to what it is. What's the point of using a cumbersome, inhuman reference for something you
  only need to talk about briefly through a computer interface?
  
  MC: SILENCE FOOL! ME DESIGN GOOD. YOU MAKE CODE MASTER ANGRY.
  
  NA: Err... but what if we just let the program rename the references temporarily to human-parseable short strings, and resolve
  what they are in between logs and commits?
  
  MC: I SAID SILENCE!! Just for that, i'm going to make you explain to a new user why we force people to regularly clean
  our their repositories after doing complicated things with them, like merging.

> Git is full of some of the worst design decisions in modern software history.

It's also full of some of the best software design decisions. The internals of Git are simple and elegant and they work like a charm. There have been very little changes to the internal workings since the first commit of Git.

I agree that the user interface is inconsistent, ugly and hard to grasp. But if you have a solid understanding of the internals, with the help of the git manpages it's pretty easy to achieve what you want.

There's software that's intended to work like a black box, just poke around the user interface and you can get stuff done. Git is not one of those. You need to understand the internal model, accept that the UI sucks, embrace the manpages, quit whining and get shit done.

I'm curious if anyone knows if the optimizations Twitter made to improve fetch performance for large, active repos have made it upstream yet? I don't work there anymore and neither do any of the people who were originally doing that work, but it was a pretty impressive speed up (I could git pull thousands of commits and be done in under a second on a 3GB repo with no large objects). I know the watchman support made it in, which was the other half of what made large repos perform well, but I haven't seen mention of the log-structured patch queue stuff that helped the server by eliminating most of the work to calculate what to send on a fetch. Anyone know?