4 ms·

In addition to what nerdponx said about recipe style articles being poor, there are some moderate issues with this article: 1. it doesn't clearly say that git

In addition to what nerdponx said about recipe style articles being poor, there are some moderate issues with this article: 1. it doesn't clearly say that git checkout with a path is irreversible. 2. it says that git reset --hard is irreversible, which is not correct. (see 3.) 3. it doesn't mention one of the most powerful git features for fixing mistakes, the reflog. 4. git remove is not a git command. 5. gitingore is not a git file. 6. git-amend is not a git command. 7. It doesn't adequately explain why force-pushing causes problems. It looks like clicking through to the gists was such a pain that even the author didn't proofread them.

nerdponx 8y ago
Oh god, I missed this one: git checkout with a path is irreversible Not only is it a reversible, but it is destructive. It will overwrite untracked changes and even untracked files, without so much as a warning. I personally consider this a critical bug in Git, but apparently the mailing list denizens do not agree with me.
- mikro2nd 8y ago
  And this is exactly the sort of behaviour that led me to call git "The Swiss Army Chainsaw of Version Control". It can do anything, but if you wield it wrong it'll cut your leg off without hesitation. I consider this a UX failure. Give me hg anytime.
  - Hello71 8y ago
    That is, broadly speaking, not correct. The reflog makes it very difficult to permanently lose committed changes, and for the most part, commands that change the working directory are generally self-evident. git checkout is really the only common command that has this non-obvious behavior, and even then, only when checking out a path; checking out a commit will warn before overwriting working directory changes. In fact, from what I read, git is far better than mercurial in this respect, as reflog is always on, whereas the journal extension must be manually enabled.
    - krupan 8y ago
      What you heard about mercurial being worse is wrong. There is no need for a journal extension to prevent mercurial from permanently deleting commits. Operations that might delete commits such as strip, rebase, etc. either saves the removed commits as a backup bundle or marks the commits as obsolete and does not ever automatically garbage collect them.
  - pjc50 8y ago
    Git is based on a one-two of UX responsibility evasion: 1) there's a distinction between the "plumbing" and the "porcelain", and all problems are blamed on the (replaceable) porcelain. So if you don't like it, use different porcelain. 2) Canonical 'git' is the only viable porcelain and we will never fix it.
- RichardCA 8y ago
  It's important to train people to be aware of the difference between clean state and dirty state. As long as you avoid dirty state you are guaranteed not to lose work. You avoid dirty state in three ways. 1. Commit your work frequently in your working branch. You can always squash later using "git reset --soft". 2. Use "git stash". 3. Create throwaway directories if all you want to do is keep your experimental files handy: mkdir temp echo '*' >temp/.gitignore Just like C forces you to be aware of how data structures are allocated internally, git forces you to have hygiene about your local file state. The only "real" problem is when your git admin fails to pay attention and make sure the top-level .gitignore and .gitattributes are set up correctly.

nerdponx 8y ago

Oh god, I missed this one: git checkout with a path is irreversible Not only is it a reversible, but it is destructive. It will overwrite untracked changes and even untracked files, without so much as a warning. I personally consider this a critical bug in Git, but apparently the mailing list denizens do not agree with me.

mikro2nd 8y ago
And this is exactly the sort of behaviour that led me to call git "The Swiss Army Chainsaw of Version Control". It can do anything, but if you wield it wrong it'll cut your leg off without hesitation. I consider this a UX failure. Give me hg anytime.
- Hello71 8y ago
  That is, broadly speaking, not correct. The reflog makes it very difficult to permanently lose committed changes, and for the most part, commands that change the working directory are generally self-evident. git checkout is really the only common command that has this non-obvious behavior, and even then, only when checking out a path; checking out a commit will warn before overwriting working directory changes. In fact, from what I read, git is far better than mercurial in this respect, as reflog is always on, whereas the journal extension must be manually enabled.
  - krupan 8y ago
    What you heard about mercurial being worse is wrong. There is no need for a journal extension to prevent mercurial from permanently deleting commits. Operations that might delete commits such as strip, rebase, etc. either saves the removed commits as a backup bundle or marks the commits as obsolete and does not ever automatically garbage collect them.
- pjc50 8y ago
  Git is based on a one-two of UX responsibility evasion: 1) there's a distinction between the "plumbing" and the "porcelain", and all problems are blamed on the (replaceable) porcelain. So if you don't like it, use different porcelain. 2) Canonical 'git' is the only viable porcelain and we will never fix it.
RichardCA 8y ago
It's important to train people to be aware of the difference between clean state and dirty state. As long as you avoid dirty state you are guaranteed not to lose work. You avoid dirty state in three ways. 1. Commit your work frequently in your working branch. You can always squash later using "git reset --soft". 2. Use "git stash". 3. Create throwaway directories if all you want to do is keep your experimental files handy: mkdir temp echo '*' >temp/.gitignore Just like C forces you to be aware of how data structures are allocated internally, git forces you to have hygiene about your local file state. The only "real" problem is when your git admin fails to pay attention and make sure the top-level .gitignore and .gitattributes are set up correctly.