3 ms·

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 se

by 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.
      - jordigh 13y ago
        > There is no difference in "git checkout <changeset" and "hg update <changeset>". NONE. WHAT. SO. EVER. There is, but you seem to be hellbent on ignoring it. And you're shouting. The difference is that a commit made there is apparently "lost" in the git UI, because it's unreferenced. After 90 days, it's actually lost, or sooner if you do a casual "git gc". This is a problem that the user needs to understand and solve. Commits in hg don't have to be referenced if you want to keep them. Hence committing at a past location in history doesn't require a lecture in hg. There is no problem to solve when you commit at an earlir commit on hg.
        Skinney 13y ago
        > There is, but you seem to be hellbent on ignoring it. And you're shouting. There isn't. There is a difference in the way git and mercurial handles anonomous branches (git removes them after a while), which i've already said a couple of times. There is however, no difference in how checkout and update works. And I'm not shouting, that would make people at this office stare, and I don't like them staring. I instead wrote in all caps as I've repeated the fact that the two commands does the exact same thing, but you seem to be hellbent on ignoring that simple fact. The commit is not lost in the git UI. You can either use "git reflog" or "git fsck --lost-found" to retrieve anonomous heads. If you want to keep them around, give them a name and you're done. If you really want to view all branches, even anonomous ones, like you can with hg log, you can use "git log --graph --decorate $(git rev-list -g --all)" > After 90 days, it's actually lost, or sooner if you do a casual "git gc". If the reflog contains the last 90 days (doesn't it default to 14 days?), that commit will remain for 90 days, unless you delete the reflog. A "git gc" doesn't change this. As the commit is still in the reflog, "git gc" can't remove it, becouse the commits are referenced by the reflog. As a side-note, git push internally calls git gc (last I checked). > There is no problem to solve when you commit at an earlir commit on hg. Actually, this creates a new head which means you either have to use a named branch or --force the push. In git you don't have to make this choice. You do however have to tell git that you want the changes to stick around by adding a reference (branch or tag) to that anonomous branch within 14 days (before the commits exit the reflog). If you're just testing something out, and find out you don't really need that code, you leave it unreferenced, and it will be removed eventually. I prefer this to manually using "hg strip" whenever storage gets low. Besides, if you create a head with work you want to keep around, why wouldn't you reference it?
  - deleted 13y ago
    [deleted]

by Skinney 13y ago

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.
    - jordigh 13y ago
      > There is no difference in "git checkout <changeset" and "hg update <changeset>". NONE. WHAT. SO. EVER. There is, but you seem to be hellbent on ignoring it. And you're shouting. The difference is that a commit made there is apparently "lost" in the git UI, because it's unreferenced. After 90 days, it's actually lost, or sooner if you do a casual "git gc". This is a problem that the user needs to understand and solve. Commits in hg don't have to be referenced if you want to keep them. Hence committing at a past location in history doesn't require a lecture in hg. There is no problem to solve when you commit at an earlir commit on hg.
      - Skinney 13y ago
        > There is, but you seem to be hellbent on ignoring it. And you're shouting. There isn't. There is a difference in the way git and mercurial handles anonomous branches (git removes them after a while), which i've already said a couple of times. There is however, no difference in how checkout and update works. And I'm not shouting, that would make people at this office stare, and I don't like them staring. I instead wrote in all caps as I've repeated the fact that the two commands does the exact same thing, but you seem to be hellbent on ignoring that simple fact. The commit is not lost in the git UI. You can either use "git reflog" or "git fsck --lost-found" to retrieve anonomous heads. If you want to keep them around, give them a name and you're done. If you really want to view all branches, even anonomous ones, like you can with hg log, you can use "git log --graph --decorate $(git rev-list -g --all)" > After 90 days, it's actually lost, or sooner if you do a casual "git gc". If the reflog contains the last 90 days (doesn't it default to 14 days?), that commit will remain for 90 days, unless you delete the reflog. A "git gc" doesn't change this. As the commit is still in the reflog, "git gc" can't remove it, becouse the commits are referenced by the reflog. As a side-note, git push internally calls git gc (last I checked). > There is no problem to solve when you commit at an earlir commit on hg. Actually, this creates a new head which means you either have to use a named branch or --force the push. In git you don't have to make this choice. You do however have to tell git that you want the changes to stick around by adding a reference (branch or tag) to that anonomous branch within 14 days (before the commits exit the reflog). If you're just testing something out, and find out you don't really need that code, you leave it unreferenced, and it will be removed eventually. I prefer this to manually using "hg strip" whenever storage gets low. Besides, if you create a head with work you want to keep around, why wouldn't you reference it?
- deleted 13y ago
  [deleted]