4 ms·

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

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

by jordigh 13y ago

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.