5 ms·

That's what 'git reset --hard' does. Read the git-reset man page: --hard Resets the index and working tree. Any changes to tracked files in the workin

That's what 'git reset --hard' does. Read the git-reset man page: --hard Resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded.

kazinator 4y ago
What changes to tracked files? What commit; I've not made one.
- silisili 4y ago
  > What commit; I've not made one. Yes, that's why it's discarded.
- taylodl 4y ago
  The git init already made a commit of the initial empty tree. That's where your HEAD is currently pointing. You staged a file and then ran git reset --hard. That took you back to your initial commit that was created by git init.
  - kazinator 4y ago
    Your claim is not correct. $ git init Initialized empty Git repository in /home/kaz/junk/gittest/.git/ $ echo content > file $ git add file $ git commit -m first-commit-not-second [master (root-commit) 2bf5805] first-commit-not-second 1 file changed, 1 insertion(+) create mode 100644 file OK, now let's reset the file to the previous commit, to stage a change which removes it from that commit: $ git reset HEAD^ -- file fatal: Failed to resolve 'HEAD^' as a valid tree. There is no commit made by git init. The above reset would work if there was a commit before HEAD. Git apologists will say anything to defend its traps and pitfalls.
kazinator 4y ago
Anyone who thinks they can mansplain git to me should read first understand my StackOverflow answer, where I give detailed instructions on how to "git stash" only the staged changes, in a git that doesn't have the recent --staged option in git stash. This is done by manipulating raw tree objects to create commits in the way stash wants them. https://stackoverflow.com/questions/14759748/how-can-i-stash-only-staged-changes-in-git/72582276#72582276 https://stackoverflow.com/questions/14759748/how-can-i-stash... I've been using this thing daily since around 2008. I think the behavior that is described by my post is suprising and poor. A command which throws away uncommitted changes removed a file whose only connection to the version control system was that its existence was announced to it. (I don't require to be informed about the mechanics of how that came about, due to what procedures being applied to what representations, all of which I understand.) People writing version control systems should take some kind of oath against anything like that happening. Under no circumstances lose any file that is not completely in version control, without confirmation.
- evgpbfhnr 4y ago
  I can try anyway: your file is still accessible with this (file content is 'foo\n') $ git cat-file --batch-all-objects --batch 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 blob 4 foo But as others said, yes I'd expect this. You wanted reset (soft). (EDIT: formatting)
- Freak_NL 4y ago
  > Anyone who thinks they can mansplain git to me […] How is dswilkerson's gender relevant here? (Or yours, given that mansplaining typically implies a man needlessly explaining something to a woman.) I don't think they've even stated that irrelevant signifier anywhere on HN.
  - leipert 4y ago
    Maybe it was a bad pun because of quoting a man page?
    - sgammon 4y ago
      okay, that was funny
- sgammon 4y ago
  “under no circumstances without confirmation” but you did that when you passed it —hard…
- alkonaut 4y ago
  Yes —hard should lose files without confirmation Yes you made a commit by initializing (your HEAD points to the state of the repo that has zero files and reset —-hard to that state means “make my repo have that empty state and don’t ask me to confirm whatever is changed or deletes in order to get there”). Git has lots of sharp edges and surprising things but this is completely unsurprising to me. I think your misunderstanding here is around what “reset —hard” does. I think with a mental model including the root (empty) state of the repo it’s easier to understand.

That's what 'git reset --hard' does. Read the git-reset man page: --hard Resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded.

kazinator 4y ago

What changes to tracked files? What commit; I've not made one.

silisili 4y ago
> What commit; I've not made one. Yes, that's why it's discarded.
taylodl 4y ago
The git init already made a commit of the initial empty tree. That's where your HEAD is currently pointing. You staged a file and then ran git reset --hard. That took you back to your initial commit that was created by git init.
- kazinator 4y ago
  Your claim is not correct. $ git init Initialized empty Git repository in /home/kaz/junk/gittest/.git/ $ echo content > file $ git add file $ git commit -m first-commit-not-second [master (root-commit) 2bf5805] first-commit-not-second 1 file changed, 1 insertion(+) create mode 100644 file OK, now let's reset the file to the previous commit, to stage a change which removes it from that commit: $ git reset HEAD^ -- file fatal: Failed to resolve 'HEAD^' as a valid tree. There is no commit made by git init. The above reset would work if there was a commit before HEAD. Git apologists will say anything to defend its traps and pitfalls.

kazinator 4y ago

Anyone who thinks they can mansplain git to me should read first understand my StackOverflow answer, where I give detailed instructions on how to "git stash" only the staged changes, in a git that doesn't have the recent --staged option in git stash. This is done by manipulating raw tree objects to create commits in the way stash wants them. https://stackoverflow.com/questions/14759748/how-can-i-stash-only-staged-changes-in-git/72582276#72582276 https://stackoverflow.com/questions/14759748/how-can-i-stash... I've been using this thing daily since around 2008. I think the behavior that is described by my post is suprising and poor. A command which throws away uncommitted changes removed a file whose only connection to the version control system was that its existence was announced to it. (I don't require to be informed about the mechanics of how that came about, due to what procedures being applied to what representations, all of which I understand.) People writing version control systems should take some kind of oath against anything like that happening. Under no circumstances lose any file that is not completely in version control, without confirmation.

evgpbfhnr 4y ago
I can try anyway: your file is still accessible with this (file content is 'foo\n') $ git cat-file --batch-all-objects --batch 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 blob 4 foo But as others said, yes I'd expect this. You wanted reset (soft). (EDIT: formatting)
Freak_NL 4y ago
> Anyone who thinks they can mansplain git to me […] How is dswilkerson's gender relevant here? (Or yours, given that mansplaining typically implies a man needlessly explaining something to a woman.) I don't think they've even stated that irrelevant signifier anywhere on HN.
- leipert 4y ago
  Maybe it was a bad pun because of quoting a man page?
  - sgammon 4y ago
    okay, that was funny
sgammon 4y ago
“under no circumstances without confirmation” but you did that when you passed it —hard…
alkonaut 4y ago
Yes —hard should lose files without confirmation Yes you made a commit by initializing (your HEAD points to the state of the repo that has zero files and reset —-hard to that state means “make my repo have that empty state and don’t ask me to confirm whatever is changed or deletes in order to get there”). Git has lots of sharp edges and surprising things but this is completely unsurprising to me. I think your misunderstanding here is around what “reset —hard” does. I think with a mental model including the root (empty) state of the repo it’s easier to understand.