
What's New In Git 1.8.5 - durdn
http://blogs.atlassian.com/2013/12/whats-new-git-1-8-5/
======
dexen
The changes look good!

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 ;-)

~~~
durdn
Hey dexen, I'm the author of the post, yes I've reported the issue before to
the internal team in charge of the blogging platform. I'll report it again.
I've also been lobbying to move our technical blog to a different technology
(I'd love a statically generated solution). Hopefully soon(tm).

~~~
Danieru
Since migrating to a new platform might be considerable work you could suggest
they install this plugin to disable the em-dash miss-feature:
[http://wordpress.org/plugins/disabler/](http://wordpress.org/plugins/disabler/)

~~~
goldenkey
I believe wrapping the text in <code> tags might be a workaround, though I
haven't tested it.

------
jheriko
was hoping to see the deadly recursive merge disabled as a default and a one
step mechanism to revert a branch.

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

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

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

~~~
ethomson
I'd be interested to hear your complaints with git-merge-recursive. Unless
your common ancestor is multiple ancestors (eg, criss-cross merges), which I
can't imagine is really commmon, it shouldn't differ appreciably from git-
merge-resolve except that it can do rename detection.

~~~
qznc
My guess would be the default "fast-forward merge when possible". In this case
there is no merge commit. When more is committed on top, you can see no trace
of a merge anymore.

------
sandyarmstrong
"While we wait for the next major git release which will bring about some
serious updates"

Is this referring to git 1.9? Are there any resources to learn what that will
bring?

~~~
adregan
I think that's referring to git 2.0—I get regular warnings when pushing repos
about the coming changes. This stack overflow question[1] (which was closed,
unfortunately) points to these "what's cooking in git" posts [2], but as far
as I can tell, there isn't a really nice walkthrough of the new features yet.

1: [http://stackoverflow.com/questions/16308484/any-
information-...](http://stackoverflow.com/questions/16308484/any-information-
on-git-2-0)

2:[http://search.gmane.org/?query=%22what%27s+cooking+in+git.gi...](http://search.gmane.org/?query=%22what%27s+cooking+in+git.git%22+%22git+2.0%22&author=Junio+C+Hamano&group=gmane.comp.version-
control.git&sort=date)

~~~
sandyarmstrong
Thanks! As @chbrosso says, these aren't exactly easy to digest, but it's nice
to have something to skim through. :-)

------
nicwolff
Yay, now I can stop doing "git fetch && git rebase -p origin/master" and go
back to "git pull --rebase".

------
Groxx
> _HEAD has a new alias, instead of typing four capital letters you can say
> “@”_

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.

~~~
jedbrown
Uh, _where_ can you use "head"?

    
    
        $ git show head
        fatal: ambiguous argument 'head': unknown revision or path not in the working tree.
        Use '--' to separate paths from revisions, like this:
        'git <command> [<revision>...] -- [<file>...]'
        $ git show head --
        fatal: bad revision 'head'
        $ git version
        git version 1.8.4.2

~~~
nteon
most likely on case-insensitive file systems, like the default HFS+ on the Mac
and NTFS on Windows.

EDIT: to expand, reference lookups are filysystem lookups:

    
    
        01:42:24 (gh-pages) [bpowers@fina myproject]$ strace git show HEAD 2>&1 | grep HEAD
        execve("/usr/bin/git", ["git", "show", "HEAD"], [/* 79 vars */]) = 0
        lstat(".git/HEAD", {st_mode=S_IFREG|0664, st_size=25, ...}) = 0
    

EDIT2: formatting

~~~
Groxx
Aaah, good point, that's probably the cause. Yeah, this is on a Mac.

------
jordigh
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".

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.

~~~
shawabawa3
What's wrong with HEAD anyway? Do we really need to save 3 characters that
badly?

git is already scary enough without stuff like

    
    
      git show @~3^2^

~~~
mikestew
Not just three chars, but three capital chars. I remapped caps lock to be the
ctrl key, and didn't put caps lock to another key because I rarely use it
anyway. For standard key mappings one still needs to hit caps lock or hold
shift while typing. Is the change revolutionary? Will it totally revitalize my
workflow? No, but it's a nice-to-have.

As for your scary example, if you don't like using "@" as an alias for HEAD,
don't do it. <shrug>

------
beagle3
Does anyone know if Git 2 is breaking repository compatibility or just command
line compatibility?

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

~~~
jedbrown
Only command-line, and only in well-announced ways, such as
push.default=simple (which you can set now) and "git add -u" run from a
subdirectory being applied globally.

