The changes look good!<p>Can't help but notice OP's blog platform replaces "--" (dash-dash) with "–" (U+2013, en dash), even in <span>s meant for code highlight. This prevents straightforward copy-paste of arguments like "--prune" to console ;-)
was hoping to see the deadly recursive merge disabled as a default and a one step mechanism to revert a branch.<p>instead a lot of relatively minor things i don't really care about (i'm sure its useful) - also seeing 'something now implemented in C' instead of 'something now 30% faster (because implemented in C)' is slightly worrying because users don't care about implementation details unless you get something else very very wrong...<p>my issue with recursive merge is that 'works for 90% of linux kernel changes' or whatever it is is just not the same as 'works reliably'.<p>git fails to meet my minimum requirements for usable source control because of the extreme difficulties I seem to have with undoing a merge if i don't change settings ahead of time (i.e. there is a bug which is a bad choice of defaults). i give it a good go, i get help from the community, i exhaust documentation and google - it doesn't work for me. maybe i don't understand something - i don't want to understand it, i want it to 'just work' and 'be user friendly'.
"While we wait for the next major git release which will bring about some serious updates"<p>Is this referring to git 1.9? Are there any resources to learn what that will bring?
><i>HEAD has a new alias, instead of typing four capital letters you can say “@”</i><p>fwiw you've been able to type "head" for quite a while (forever?). TYPING IN ALL CAPS is a bit of a pain, I agree, but at least for me "head" is somewhere on the same level of typing-complexity as @, possibly easier.
Sigh, why use "@" for HEAD? The currently checked-out commit should be called ".", just like the current directory. Doesn't this make more sense? A Unix person thinks "." means "this one" or "current".<p>I only complain because in hg, "." is the equivalent to git's HEAD, and it's already difficult enough for git users to understand any system other than git after they spend time learning its idiosyncratic and inconsistent UI.
Does anyone know if Git 2 is breaking repository compatibility or just command line compatibility?<p>I remember Linus wanted to add a "generation" counter (empty commit=0, other commits=1+max(parent commits)) to speed up some merges; And I know I would love changes that would make big files properly supported (e.g. the way bup efficiently handles huge files inside a git repo).