3 ms·

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

by nox_ 13y ago

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
        > they would not require a lecture to understand how to recover a commit made on a detached HEAD, a lecture that git provides. The only real difference here compared to Mercurial is that Mercurial doesn't issue a warning/lecture... In both cases you will have to know the changeset (or revision number in Mercurial) to get back to that anonomous branch (unless it's tip, but tip has its own issues). Git providing a warning for this is fair imho, as Git garbage collects anonomous branches. That, however, does not change the fact that checking out a random commit and a branch are the same thing in UI and implementation.
- 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.

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

by nox_ 13y ago

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

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
        > they would not require a lecture to understand how to recover a commit made on a detached HEAD, a lecture that git provides. The only real difference here compared to Mercurial is that Mercurial doesn't issue a warning/lecture... In both cases you will have to know the changeset (or revision number in Mercurial) to get back to that anonomous branch (unless it's tip, but tip has its own issues). Git providing a warning for this is fair imho, as Git garbage collects anonomous branches. That, however, does not change the fact that checking out a random commit and a branch are the same thing in UI and implementation.
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.