-1

I was going to unstage a file, but instead of typing:

git reset file.sh

I typed:

git reset file.sh head

And the output was:

Unstaged changes after reset:
M       path/file1
M       path/file2
M       path/file2
....
^C

I know from git documentation that git reset has three forms

git reset [-q] [<tree-ish>] [--] <paths>...
git reset (--patch | -p) [<tree-ish>] [--] [<paths>...]
git reset [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>]

But my command don't match any of the three forms.

My question is: what happened here? And Why the command operated on all my repository?

EDIT: Actually, file.sh exists, but head don't. If I use

git reset existing.file nonexisting.file

it will change the index on existing.file and will ignore the second file, and show the full list of unstaged file (normal, but resulted in a bit of panic).

If I type:

git reset nonexisting.file existing.file

it will fail. http://paste.ubuntu.com/12780596/.

Thanks to @sehe to pointing to the correct solution.

Francisco Delmar Kurpiel
  • 376
  • 3
  • 14

1 Answers1

3

It just ignored the head part (assuming that's not a file).

To force git to interpret arguments as paths (e.g. when unstaging a file deletion), use --

git reset HEAD -- some/path
sehe
  • 374,641
  • 47
  • 450
  • 633
  • And what about the "file.sh" parameter? It was ignored too? If this is true, git ignored everything after "reset" and started unstaging my whole working copy? – Francisco Delmar Kurpiel Oct 13 '15 at 21:09
  • I don't know. Give use complete steps to reproduce and I'll tell you. – sehe Oct 13 '15 at 21:10
  • Just take a repository with some changed files and run "git reset file.sh head". You'll see that instead of reporting invalid parameters, or trying to reset two files, named "file.sh" and "head" it will reset all files. – Francisco Delmar Kurpiel Oct 13 '15 at 21:29
  • The output: http://paste.ubuntu.com/12775919/ - nothing gets ignored. The output message suggests exactly what I did. Check `git config -l | grep alias` maybe? Or `type git` etc. – sehe Oct 13 '15 at 21:38
  • 1
    This is the correct answer: `git reset` treats all otherwise-unknown arguments as paths. If you `git reset` a path that's not in the index, that's a no-op: `git reset arglebargle` does nothing to the index All the rest of the output is a result of `git reset` doing `git status` after it's finished resetting. – torek Oct 13 '15 at 22:05
  • 1
    I'm very sorry, @sehe, _file.sh_ actually *exists*, just _head_ don't. http://paste.ubuntu.com/12780492. Also, the bit that confused (and scared me) was the list of all unstaged files. But it does that even when I used "git reset" correctly. Apparently, if the first argument exists as a file it will accept other arguments as paths as consider them as no-op, as torek said. If the first argument (after reset) don't exist it fails: http://paste.ubuntu.com/12780546. Sorry for misreporting the initial problem. – Francisco Delmar Kurpiel Oct 14 '15 at 12:48