9 ms·

What's New In Git 1.8.5

116 points by durdn 13y ago

jordigh 13y 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_ 13y ago
  No, "git checkout ." already has meaning, you can't reuse . for a committish value.
  - jordigh 13y 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.
    - quarterto 13y ago
      (1) and (2) are the same. Branches are pointers to commits.
      - jordigh 13y ago
        No, you can checkout any commit, not just a commit with a branch ref on it. It's a different thing because one of these require a detached HEAD lecture and the other one doesn't.
        Crito 13y ago
        Detached just means that your HEAD is a commit, not a ref. There is no particular reason for git-commit to care if a commit is pointed to by a branch, some other sort of ref, is reachable from a commit that is pointed to by a branch or other sort of ref, or detached from everything at all. If you read the code, it is doing the same thing in either case, only differentiating between them to print more useful messages for the users benefit and make sure the user is doing what they really want to do in situations that may be destructive (without falling back on reflog). They really are the same thing.
        jordigh 13y ago
        > They really are the same thing. They're only the same thing at a fundamental level, just like eventually all a computer is doing is moving bits around and all data is a bit stream. This ignores that hey are not treated as the same thing from the UI point of view. If they were, they would not require a lecture to understand how to recover a commit made on a detached HEAD, a lecture that git provides.
        Crito 13y ago
        They are treated as the same thing at the UI level, hence your complaint. If they were treated as unrelated concepts then they would not both be serviced by git-checkout, despite sharing an underlying implementation. They are the same thing both in implementation and UI. The various consequences of detached commits and what happens when you try to modify the working tree when there are uncommitted changes are both concepts that permeate all of git. Handling these things in a graceful manner does not somehow mean that checking out branches or commits are fundamentally different concepts. If you want an example of muddled UI, git-checkout -b is an infinitely better example. Creating a branch is conceptually unrelated to checking out a branch; git-checkout just provides the -b flag for convenience because typically you want to check out the branch after creating it. It would likely make more sense to provide a --checkout flag of some sort with git-branch, as creating the branch is the primary operation and checking it out is just a secondary convenience. That is a decent complaint. If this is the sort of thing honestly that bothers you, then just make a git-changebranch alias for git-checkout, pretend that git-checkout can't do branches even though it can do arbitrary commits, and move on with your life.
    - Skinney 13y ago
      Actually (1) (2) and (3) are doing the exact same thing. You are retrieving (checking out... checkout) files from storage. "git checkout HEAD" makes perfect sense in this case, cause you are checking out files from the commit pointed at by HEAD. Of course, checkout doesn't overwrite files in the working directory that are modified, unless you provide the -f option. (4) is a convinience option and is more like "git branch <name> && git checkout <name>" Mercurial also does 'crazy stuff' like this. Like "hg pull --update" which is really just "hg pull && hg update". I also don't understand what about "Detached HEAD" requires a lesson? Detached HEAD just means that the current HEAD doesn't isn't pointed at by a branch pointer. You have the same thing in Mercurial, it just doesn't warn about it. It's not really that big a deal in Mercurial either, as anonomous heads aren't in danger of being garbage collected.
      - jordigh 13y ago
        > I also don't understand what about "Detached HEAD" requires a lesson? git lectures you when you do this. That's the lesson.
        Skinney 13y ago
        Ah, right. That's only the first time though right? Don't really consider this as a negative.
        jordigh 13y ago
        The first time per repo, unless you disable it globally. It's a negative because if your UI is so complicated that you need to lecture your users, then you are doing something wrong. Your users should be able to use the software without getting lectured.
        Skinney 13y ago
        How do you twist this to be a result of complicated UI? Git gives a helpfull reminder that commits on a detached HEAD results in a anonomous branch. The only difference from say Mercurial, is that Git warns about this. There is no difference in "git checkout <changeset" and "hg update <changeset>". NONE. WHAT. SO. EVER. Except that Git gives you a warning that commits on this changeset results in an anonomous branch. And Git is filled with helpfull texts like this. Git status tells you how to revert files. Git rebase tells you how to abort. I personally find this as something positive, as I don't have to lookup documentation whenever I want to do something.
- mitchty 13y 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.
  - jordigh 13y 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!
    - mitchty 13y ago
      To be honest I don't see the issue at all here. Fundamentally the following all make sense to me intuitively: git checkout dir (lets assume cwd is in a git repo) cd dir && git checkout . And for completeness: git checkout file I don't buy the argument that something could be a path or a ref is bad in this case. It allows for both common cases simply. Want to update a single file/directory git checkout that file. Want to checkout a revision? Checkout the sha1hash. Basically what I'm saying here, is reusing '.' is more of a problem for hg in that they're repurposing an already common idiom in unix. If my arguments to why aren't convincing we'll have to disagree that this is a git "fault" or "inconsistent ui". I think of it as neither however.
      - jordigh 13y ago
        This is not "completeness". These are fundamentally different things, like I explained in another comment. You even used a different verb for the file case, "update a file", which coincidentally matches closer the verb that hg uses, "update". Here, this is a funnier way to explain why "git checkout" is such a weird command: http://stevelosh.com/blog/2013/04/git-koans/#one-thing-well http://stevelosh.com/blog/2013/04/git-koans/#one-thing-well
- shawabawa3 13y 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 13y 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 13y 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 13y ago
  I would think that introducing an alias for a pointer which could be confused for a filesystem path would be more confusing than "@".
- Crito 13y 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.
  - jordigh 13y 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.
    - Crito 13y ago
      > Of course commits are not directories, but it's a good UI analogy Why is it a good analogy? Directories are doubly linked trees^, each directory containing references to all child directories and a single parent directory, with some spacial implications (it makes sense to talk about directories being in or containing other directories). Commits make up singly linked DAGs, with each commit only having references to potentially many parent commits but no child commits, with strong temporal implications (it makes sense to talk about commits preceding or following other commits, with distant simultaneity frequently making an appearance). These two concepts really have very little overlap, other than both being graphs. Even if we just decided that "HEAD"->"." anyway, we can't keep that up for long. What the hell would ".." become? "HEAD^" might seem like the obvious answer, but you would be left to figure out what the "directory equivalent" of "HEAD^2" is. "HEAD~2^2"? The Unix relative directory language is not expressive enough for git, even if you want to force the analogy for some reason. Directories could be a good analogy for git's tree objects, but you operate on those through the high-level porcelain. There are certainly problems with git's porcelain, and there are obvious improvements to be made, but this is not one of them. ^barring symbolic links, which we can ignore unless we want to open a whole 'Unix Haters Handbook'-esque can of worms...
      - 13y ago
- deleted 13y ago
  [deleted]
- philsnow 13y 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.
  - jordigh 13y 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 13y 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 13y 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 13y 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 13y 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/ http://wordpress.org/plugins/disabler/
    - goldenkey 13y ago
      I believe wrapping the text in <code> tags might be a workaround, though I haven't tested it.
- contingencies 13y ago
  –=--
jheriko 13y 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'.
- justinhj 13y 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.
  - Osiris 13y 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?
    - jheriko 13y ago
      nope. if i merge two branches, push that to the remote and i wan't to undo it.
      - Crito 13y ago
        So push your fix? Push hard if necessary, and if your remote forbids non-fastforward pushes even with force, then delete the remote branch and recreate it under the same name with the commit that you want.
sandyarmstrong 13y 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 13y 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-on-git-2-0 http://stackoverflow.com/questions/16308484/any-information-... 2: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 http://search.gmane.org/?query=%22what%27s+cooking+in+git.gi...
  - sandyarmstrong 13y ago
    Thanks! As @chbrosso says, these aren't exactly easy to digest, but it's nice to have something to skim through. :-)
- chbrosso 13y 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 13y ago
Yay, now I can stop doing "git fetch && git rebase -p origin/master" and go back to "git pull --rebase".
beagle3 13y 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).
- jedbrown 13y 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.
Groxx 13y 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.
- jedbrown 13y 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 13y 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
    - Groxx 13y ago
      Aaah, good point, that's probably the cause. Yeah, this is on a Mac.
- scott_karana 13y ago
  It's also definitely more transparent for a new user. git rebase @~4 looks like Perl :)

116 points by durdn 13y 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_ 13y ago
No, "git checkout ." already has meaning, you can't reuse . for a committish value.
- jordigh 13y 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.
  - quarterto 13y ago
    (1) and (2) are the same. Branches are pointers to commits.
    - jordigh 13y ago
      No, you can checkout any commit, not just a commit with a branch ref on it. It's a different thing because one of these require a detached HEAD lecture and the other one doesn't.
      - Crito 13y ago
        Detached just means that your HEAD is a commit, not a ref. There is no particular reason for git-commit to care if a commit is pointed to by a branch, some other sort of ref, is reachable from a commit that is pointed to by a branch or other sort of ref, or detached from everything at all. If you read the code, it is doing the same thing in either case, only differentiating between them to print more useful messages for the users benefit and make sure the user is doing what they really want to do in situations that may be destructive (without falling back on reflog). They really are the same thing.
        jordigh 13y ago
        > They really are the same thing. They're only the same thing at a fundamental level, just like eventually all a computer is doing is moving bits around and all data is a bit stream. This ignores that hey are not treated as the same thing from the UI point of view. If they were, they would not require a lecture to understand how to recover a commit made on a detached HEAD, a lecture that git provides.
        Crito 13y ago
        They are treated as the same thing at the UI level, hence your complaint. If they were treated as unrelated concepts then they would not both be serviced by git-checkout, despite sharing an underlying implementation. They are the same thing both in implementation and UI. The various consequences of detached commits and what happens when you try to modify the working tree when there are uncommitted changes are both concepts that permeate all of git. Handling these things in a graceful manner does not somehow mean that checking out branches or commits are fundamentally different concepts. If you want an example of muddled UI, git-checkout -b is an infinitely better example. Creating a branch is conceptually unrelated to checking out a branch; git-checkout just provides the -b flag for convenience because typically you want to check out the branch after creating it. It would likely make more sense to provide a --checkout flag of some sort with git-branch, as creating the branch is the primary operation and checking it out is just a secondary convenience. That is a decent complaint. If this is the sort of thing honestly that bothers you, then just make a git-changebranch alias for git-checkout, pretend that git-checkout can't do branches even though it can do arbitrary commits, and move on with your life.
  - Skinney 13y ago
    Actually (1) (2) and (3) are doing the exact same thing. You are retrieving (checking out... checkout) files from storage. "git checkout HEAD" makes perfect sense in this case, cause you are checking out files from the commit pointed at by HEAD. Of course, checkout doesn't overwrite files in the working directory that are modified, unless you provide the -f option. (4) is a convinience option and is more like "git branch <name> && git checkout <name>" Mercurial also does 'crazy stuff' like this. Like "hg pull --update" which is really just "hg pull && hg update". I also don't understand what about "Detached HEAD" requires a lesson? Detached HEAD just means that the current HEAD doesn't isn't pointed at by a branch pointer. You have the same thing in Mercurial, it just doesn't warn about it. It's not really that big a deal in Mercurial either, as anonomous heads aren't in danger of being garbage collected.
    - jordigh 13y ago
      > I also don't understand what about "Detached HEAD" requires a lesson? git lectures you when you do this. That's the lesson.
      - Skinney 13y ago
        Ah, right. That's only the first time though right? Don't really consider this as a negative.
        jordigh 13y ago
        The first time per repo, unless you disable it globally. It's a negative because if your UI is so complicated that you need to lecture your users, then you are doing something wrong. Your users should be able to use the software without getting lectured.
        Skinney 13y ago
        How do you twist this to be a result of complicated UI? Git gives a helpfull reminder that commits on a detached HEAD results in a anonomous branch. The only difference from say Mercurial, is that Git warns about this. There is no difference in "git checkout <changeset" and "hg update <changeset>". NONE. WHAT. SO. EVER. Except that Git gives you a warning that commits on this changeset results in an anonomous branch. And Git is filled with helpfull texts like this. Git status tells you how to revert files. Git rebase tells you how to abort. I personally find this as something positive, as I don't have to lookup documentation whenever I want to do something.
mitchty 13y 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.
- jordigh 13y 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!
  - mitchty 13y ago
    To be honest I don't see the issue at all here. Fundamentally the following all make sense to me intuitively: git checkout dir (lets assume cwd is in a git repo) cd dir && git checkout . And for completeness: git checkout file I don't buy the argument that something could be a path or a ref is bad in this case. It allows for both common cases simply. Want to update a single file/directory git checkout that file. Want to checkout a revision? Checkout the sha1hash. Basically what I'm saying here, is reusing '.' is more of a problem for hg in that they're repurposing an already common idiom in unix. If my arguments to why aren't convincing we'll have to disagree that this is a git "fault" or "inconsistent ui". I think of it as neither however.
    - jordigh 13y ago
      This is not "completeness". These are fundamentally different things, like I explained in another comment. You even used a different verb for the file case, "update a file", which coincidentally matches closer the verb that hg uses, "update". Here, this is a funnier way to explain why "git checkout" is such a weird command: http://stevelosh.com/blog/2013/04/git-koans/#one-thing-well http://stevelosh.com/blog/2013/04/git-koans/#one-thing-well
shawabawa3 13y 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 13y 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 13y 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 13y ago
I would think that introducing an alias for a pointer which could be confused for a filesystem path would be more confusing than "@".
Crito 13y 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.
- jordigh 13y 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.
  - Crito 13y ago
    > Of course commits are not directories, but it's a good UI analogy Why is it a good analogy? Directories are doubly linked trees^, each directory containing references to all child directories and a single parent directory, with some spacial implications (it makes sense to talk about directories being in or containing other directories). Commits make up singly linked DAGs, with each commit only having references to potentially many parent commits but no child commits, with strong temporal implications (it makes sense to talk about commits preceding or following other commits, with distant simultaneity frequently making an appearance). These two concepts really have very little overlap, other than both being graphs. Even if we just decided that "HEAD"->"." anyway, we can't keep that up for long. What the hell would ".." become? "HEAD^" might seem like the obvious answer, but you would be left to figure out what the "directory equivalent" of "HEAD^2" is. "HEAD~2^2"? The Unix relative directory language is not expressive enough for git, even if you want to force the analogy for some reason. Directories could be a good analogy for git's tree objects, but you operate on those through the high-level porcelain. There are certainly problems with git's porcelain, and there are obvious improvements to be made, but this is not one of them. ^barring symbolic links, which we can ignore unless we want to open a whole 'Unix Haters Handbook'-esque can of worms...
    - 13y ago
deleted 13y ago
[deleted]
philsnow 13y 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.
- jordigh 13y 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 13y 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 13y 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 13y 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 13y 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/ http://wordpress.org/plugins/disabler/
  - goldenkey 13y ago
    I believe wrapping the text in <code> tags might be a workaround, though I haven't tested it.
contingencies 13y ago
–=--

jheriko 13y 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'.

justinhj 13y 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.
- Osiris 13y 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?
  - jheriko 13y ago
    nope. if i merge two branches, push that to the remote and i wan't to undo it.
    - Crito 13y ago
      So push your fix? Push hard if necessary, and if your remote forbids non-fastforward pushes even with force, then delete the remote branch and recreate it under the same name with the commit that you want.

sandyarmstrong 13y 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 13y 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-on-git-2-0 http://stackoverflow.com/questions/16308484/any-information-... 2: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 http://search.gmane.org/?query=%22what%27s+cooking+in+git.gi...
- sandyarmstrong 13y ago
  Thanks! As @chbrosso says, these aren't exactly easy to digest, but it's nice to have something to skim through. :-)
chbrosso 13y 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 13y ago

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

beagle3 13y 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).

jedbrown 13y 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.

Groxx 13y 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.

jedbrown 13y 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 13y 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
  - Groxx 13y ago
    Aaah, good point, that's probably the cause. Yeah, this is on a Mac.
scott_karana 13y ago
It's also definitely more transparent for a new user. git rebase @~4 looks like Perl :)