git: mv command

Question

i've read that the mv command is basically the same as

$ mv README.txt README
$ git rm README.txt
$ git add README

just to be sure, is it exactly the same if i do it this way:

$ git rm --cached README.txt
# [rename file using right click rename]
$ git add README

As someone told me someday: Have you considered accept one of this answers as the right one, or give more details of what you're really wanting so that we can improve ours and you get news? — Gabriel L. Oliveira, Apr 30 '11 at 11:38
@Gabriel L. Oliveira i've added more details in the replies of the answers.. — Pacerier, May 01 '11 at 00:00

Gabriel L. Oliveira · Accepted Answer · 2011-04-28T04:32:01.363

6

No. the --cached param is recommended when what you want is unstage and remove paths (in this case, the README.txt) only from the index. Working tree files, whether modified or not, will be left alone.

A better approach, on this case that is renaming a file, is use the build-in mv command of git. So:

$ git mv README.txt README

would have the same effect as you first approach, but with less type.

Font: http://www.kernel.org/pub/software/scm/git/docs/git-rm.html

edited Apr 28 '11 at 04:32

answered Apr 28 '11 at 04:26

Gabriel L. Oliveira

3,922
6
31
40

1

heys sorry i don't really get what you mean when you say **working tree files**.. – Pacerier Apr 30 '11 at 23:57
btw do you mean to say that actually both are the same but 1 is recommended over the other depending on the purpose (although either choice would have the files ended up with exactly the same state?) – Pacerier Apr 30 '11 at 23:58
1

@Pacerier "working tree files" mean your real files (saved on your harddisk). When you use `git rm`, git really remove the file from your disk, while using `git rm --cached` only remove the file from the index (HEAD of your commit), lefting the file (modified or not) on your hardisk. What I mean is that, instead of using both solutions, the use of `git mv` is the better one, because do what you want with a single command. Also, make the git tree know it as a move (rename, whatever), and not as a "totally new file". Got it? – Gabriel L. Oliveira May 02 '11 at 08:30
1

ok cool i got the part on "working tree files". However isn't it that either way we do it, Git will think that its a "totally new file" anyway instead of a "move" (since git really has no idea of a move) so basically what im wondering is that is there any difference in the "meta-data" that git will generate when we compare 1) with 2) – Pacerier May 02 '11 at 09:18
@Pacerier Well, I think no, because on both ways you'll get the same thing. A `rm` on a file and an `add` on another file (what `rm` do at once). – Gabriel L. Oliveira May 02 '11 at 09:38

score 4 · Answer 2 · edited May 23 '17 at 11:47

4

See What's the purpose of git-mv?.

Yes, it's pretty much the same.

edited May 23 '17 at 11:47

Community

1
1

answered Apr 28 '11 at 04:26

JohnD

3,884
1
28
40

score 3 · Answer 3 · edited May 23 '17 at 12:29

3

See git mv records move?

It's the same.

edited May 23 '17 at 12:29

Community

1
1

answered Apr 28 '11 at 04:39

Mot

28,248
23
84
121

i've read the link but it doesn't tell me whether my first choice is the same as my second choice in the question.. – Pacerier May 01 '11 at 00:00

git: mv command

3 Answers3