Any difference to unstage files using "git checkout" and "git rm"

Hi,

Is there any difference between the below 2 commands ? I didn't see anything.

git rm --cached -- <file1> .. <fileN>
git checkout -- <file1> .. <fileN>

===============
Regards,
Arup Rakshit

This one removes the index entries for those files.

This one checks out the content from the index into the working tree (for just those files).

Try:

  # setup...
  git init
  echo content >file
  git add file
  git commit -m one

  # now rm
  git rm --cached -- file
  git status

which yields:

rm 'file'

On branch master
Changes to be committed:
deleted: file

Untracked files:
file

but it we restore our state and try checkout:

git reset
git checkout -- file

nothing happens:

On branch master
nothing to commit, working directory clean

but if you had changes in the working tree:

echo changes >file
git status | sed 's/^/before> /'
git checkout -- file
git status | sed 's/^/ after> /'

you get:

before> On branch master
before> Changes not staged for commit:
before> modified: file
before>
before> no changes added to commit

after> On branch master
after> nothing to commit, working directory clean

Does that help?

-Peff

Please Ignore the previous.

I apologize to rewriting and increase the load of this mailing list. I actually wanted to ask the below

git rm -- cached -- <file1> .. <fileN>
git reset HEAD <file1> .. <fileN>

===============
Regards,
Arup Rakshit

For me who is in Git just 6-7 days, It is huge. On your way, I was walking to test those out. But I got some messages from Git, which made me confused to think, about the *philosophy of those*.

arup@linux-wzza:~> mkdir Git_tutorial
arup@linux-wzza:~> cd Git_tutorial/ arup@linux-wzza:~/Git_tutorial> LS
If 'LS' is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf LS
arup@linux-wzza:~/Git_tutorial> ls arup@linux-wzza:~/Git_tutorial> echo "welcome to git" > test.txt arup@linux-wzza:~/Git_tutorial> ls
test.txt
arup@linux-wzza:~/Git_tutorial> git init
Initialized empty Git repository in /home/arup/Git_tutorial/.git/ arup@linux-wzza:~/Git_tutorial> git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# test.txt
nothing added to commit but untracked files present (use "git add" to track) arup@linux-wzza:~/Git_tutorial> git add test.txt arup@linux-wzza:~/Git_tutorial> git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: test.txt
#

NOTE :- While, I have a new file in my repository, and I staged it, it is telling me to unstage it using *git rm -- cached <file>*. But once I committed, and the file became a tracked file in my repository, *Git* internal message got changed, *for unstaging*, Which is why, I asked this question. Look below -

arup@linux-wzza:~/Git_tutorial> git commit -m "commit1" [master (root-commit) 20bf27f] commit1

 1 file changed, 1 insertion(+)
 create mode 100644 test.txt

arup@linux-wzza:~/Git_tutorial> echo "How are you enjoying?" > test.txt arup@linux-wzza:~/Git_tutorial> git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: test.txt
#
no changes added to commit (use "git add" and/or "git commit -a") arup@linux-wzza:~/Git_tutorial> git add test.txt arup@linux-wzza:~/Git_tutorial> git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: test.txt
#
arup@linux-wzza:~/Git_tutorial>

It is now telling to USE "git reset HEAD <file>..." to unstage, NOT "git rm
--cached <file>..." to unstage.

Please let me know, If I am making you guys more confused.

===============
Regards,
Arup Rakshit

Too late. :)

OK, this is a more sensible comparison.

The first command will remove the entries from the index entirely, and the second one will return them to their state in HEAD. So _if_ the existing commit in HEAD did not have the files at all, the two are identical.

But if the files were committed previously, then the second command will return them to that state, not remove them entirely.

Does that make sense?

-Peff