What's New In Git 1.8.5

http://blogs.atlassian.com/2013/12/whats-new-git-1-8-5/

by durdn • 13 years ago

116 71 13 years ago

blogs.atlassian.com

jordigh12• 13 years ago

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.

nox_• 13 years ago

No, "git checkout ." already has meaning, you can't reuse . for a committish value.

jordigh12• 13 years ago

Ah, so it's a problem with working around the existing awful UI. So, "git checkout" does four different things parsing all of which requires a lot of context: (1) switch branches (2) visit an arbitrary commit (3) revert a file (4) create a new branch.

And it's not as if "git checkout HEAD" makes any sense either, this is a no-op, since you can't be on anything but HEAD.

mitchty3• 13 years ago

I've used unix pretty much my entire computing life and outside of dealing with files and directories I've NEVER thought of . as meaning anything but the directory entry I'm in.

Comparing git to hg here is bad, as pointed out previously, '.' really does mean something more akin to what unix has always meant. I'd argue hg is more in the wrong here with reusing '.' as having other meanings for something that could semantically refer to a directory under version control.

Bitch about gits interface all you want, but not using '.' is between you and me a crap argument if you're going to invoke the "unix person" gods.

jordigh12• 13 years ago

Well, another problem with git's interface is that it allows interpreting an argument as a path or as a ref, most notably in "git checkout" which does a bunch of different unrelated things. If "git checkout ." couldn't be interpreted as a current directory, this problem doesn't exist. It's another case of a wildly inconsistent UI, the same command doing a bunch of unrelated things with the same syntax!

shawabawa3• 13 years ago

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• 13 years ago

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>

cespare• 13 years ago

I thought HEAD was too hard to type and have been using $h (zsh alias) for HEAD for a few years.

I'll be glad to save another 1 character with 1.8.5.

brown9-2• 13 years ago

I would think that introducing an alias for a pointer which could be confused for a filesystem path would be more confusing than "@".

Crito7• 13 years ago

Commits are not directories. I don't know why you would want to muddle the two concepts, but doing so would make git's UI more inconsistent and would break the principle of least suprise moreso than it is right now.

Just because Mercurial does it, doesn't mean that it is thought out or makes sense.

jordigh12• 13 years ago

Of course commits are not directories, but it's a good UI analogy. In any context where hg accepts a revision number, it doesn't also accept a path, so there's no possible ambiguity, but git's UI requires lots of ambiguous parsing. An example of this is how many git users get in the habit of cargo-culting "--" to separate paths from options.

philsnow• 13 years ago

@ is the traditional identifier for "the adventurer" in roguelikes, possibly because it looks rather like a top-down view of indiana jones wearing a fedora.

roguelikes and unices grew up together, and there's a fair amount of intermingling of concepts and jargon.

...okay the reason is probably more like "'@' means 'you are here'", but I like this justification better because it's how it was explained to me at age ~7 when my dad was teaching me how to play nethack.

jordigh12• 13 years ago

Haha, that's a cute explanation.

In hg, "@" is a special bookmark that gets checked out in new clones. There it means "this is where you probably want to be".

perlgeek• 13 years ago

There are often-used commands (log, diff, checkout come to mind) that can either take commits or file names on the command line, and most disambiguate to commits. If you introduce . as an alias for HEAD, you either have to change the disambiguation rule, or you must change the meaning of commonly used idioms. Both approaches break backwards compatibility.

dexen• 13 years ago

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• 13 years ago

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• 13 years ago

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/

contingencies• 13 years ago

–=--

jheriko3• 13 years ago

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

justinhj3• 13 years ago

I'd say I'm quite proficient with git but undoing merges is something I dread having to do because the documentation for it is so complicated.

Osiris3• 13 years ago

What do you mean by undoing a merge? I assume you're talking about something more complicated than what I usually do

    git reset --hard HEAD~

That just kicks you back to the commit just prior to your current (merge) commit. Are you talking about trying to undo a merge further back in the commit history?

ethomson• 13 years ago

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• 13 years ago

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.

jheriko3• 13 years ago

my complaint is exactly the comment i made. 'works most of the time in one situation' is not working. its a bit magical - i've only seen it do something insane once and i can't remember the specifics, but it introduced me to the concept and made me want to turn it off.

i really don't mind conflicts. safety over rushing every time...

sandyarmstrong2• 13 years ago

"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• 13 years ago

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

2:http://search.gmane.org/?query=%22what%27s+cooking+in+git.gi...

sandyarmstrong2• 13 years ago

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

chbrosso• 13 years ago

This refers to Git 2.0, that will bring breaking changes, like the default push mode. I don't know any other source than the weekly "what's cooking in Git" posts by Git maintainer on the mailing list, but it's fairly hard to read if you're not used to Git internals.

nicwolff• 13 years ago

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

beagle3• 13 years ago

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

jedbrown2• 13 years ago

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.

Groxx2• 13 years ago

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.

jedbrown2• 13 years ago

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• 13 years ago

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

scott_karana• 13 years ago

It's also definitely more transparent for a new user.

git rebase @~4 looks like Perl :)

What's New In Git 1.8.5

Related Stories