Vscode: Renaming file marks for git delete but not git add

[leegee]

• VSCode Version: 0.10.13-insider
• OS Version: Microsoft Windows [Version 10.0.10586]

Steps to Reproduce:

1. Open a folder of a project using git version control
2. In VCS 'Explorer', right-click file in the folder view (under Working Files) and rename it
3. Switch to Git view.
4. Notice that old name of the file is marked D for delete, and the new name is U for untracked.
5. Outside of VCS, use git mv to rename a file, and see VCS correctly picks up the change as 'R' (presumably for 'renamed').

[joaomoreno]

This is expected.

If you do the rename using the Windows Explorer and run git status they will also show as deleted and added files. It's just how git works. Once you commit, rename detection will occur and it everything will be logged as renames by git.

[leegee]

* Renaming file marks for git delete but not git add *

I don't use Windows Explorer, but look at this bash output that will show you how to rename a file under git:

$ git mv foo bar
$ git status -s
    R  foo -> bar

Notice the R for rename.

It seems your product is doing this:

$ mv foo bar
$ git status -s
     D foo
    ?? bar

Would you like to re-open this ticket, or should I create a new one and reference this one?

[joaomoreno]

That only works because you are calling git mv which automatically stages your files.

The correct analogy to what Code does - that is, without the staging - is to run mv foo bar instead of git mv foo bar.

[leegee]

Exactly -- that's why I filed a bug report, because Code mishandles version-controlled files.
Note that what git actually does is to add the file to version control, whilst Code removes it from version control.
As a user, I expect renaming a file to have no side-effects -- certainly not to change its state in version control.

[joaomoreno]

Code doesn't mishandle version-controlled files. Code works (and should work) just like the Windows Explorer here. It works just like you'd rename a file regardless of git. It works just as you'd run mv foo bar in the command line. All of these will make git detect a delete and an add.

Once you stage both those operations, git will detect that as a move.

git mv foo bar does these two steps at once: it moves the files and then stages the delete and the add.

Code shouldn't do that automatically. Let me give you a simple situation why that is:

1. make changes to foo
2. stage those changes
3. rename foo to bar

After those steps, Code will still let you commit the initial changes to foo without committing the rename. If Code would automatically stage the move, you'd be stuck with the combination of the file changes and the rename in your staging area, which might not be what you wanted.

[leegee]

I do not think it is a question of 'what [I] want' but what I expect.

As I said, I do not expect renaming a file to remove it from version
control.

I am not a regular user of Windows Explorer, so my expectations do not come
from that domain. I am a regular user of git and Linux, so am used to
moving files to rename them.

I'll give up on this issue now -- I am sure someone else will raise it in
the future. Very disappointed to VS Code so obstinate on what seems to be a
straight-forward usability issue.

On 4 April 2016 at 10:29, João Moreno [email protected] wrote:

Code doesn't mishandle version-controlled files. Code works (and should
work) just like the Windows Explorer here. It works just like you'd rename
a file regardless of git. It works just as you'd run mv foo bar in the
command line. All of these will make git detect a _delete_ and an _add_.

Once you _stage_ both those operations, git will detect that as a _move_
http://stackoverflow.com/questions/7938582/how-does-git-detect-similar-files-for-its-rename-detection
.

git mv foo bar does these two steps at once: it moves the files and then
stages the _delete_ and the _add_.

Code shouldn't do that automatically. Let me give you a simple situation
why that is:

1. make changes to foo
2. stage those changes
3. rename foo to bar

After those steps, Code will still let you commit the initial changes to
foo without committing the rename. If Code would automatically stage the
move, you'd be stuck with the combination of the file changes and the
rename in your staging area, which might not be what you wanted.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/vscode/issues/4821#issuecomment-205211135

[joaomoreno]

I don't know how else to put it: Code shouldn't stage on move, in the same way that it doesn't stage on file creation and deletion.

[leegee]

It's the 'should not' that I am querying -- why should it not? What is Code trying to be? Is there a mission statement...?
I agree that newly created files should not be staged, because I have never met anyone who would expect a new file to automatically be considered as version-controlled.
However, when an operation is performed upon a file that is under version control, I suppose most people would expect the operation to effect the state in version control. Thus, when I use code to delete a file under version control, I expect to see it marked as deleted in version control -- and it is. Naturally, then, when I use Code to rename a file, I expect....etc.
We don't know if my supposition is correct, nor if yours is, and since I have not seen a formal objective for Code, I cannot comment further without chasing my own tail.
Perhaps a new ticket, "More Integration with VCS: context menu add/remove/delete/rename" :-)

[joaomoreno]

It's not a question of a lack of a mission statement, it's about consistency.

I explained the reason: because the user doesn't necessarily wants to stage a rename when he's just performed it. The same way that the user doesn't want to stage the creation of a file as soon as he does it. Or a deletion. Or a text edit. Or any other operation.

When you add a file it appears as an untracked file in git. And Code shows it as added. But it's not staged. Yet, Code is nice and still lets you commit that without staging, by typing in a message and pressing Commit.

When you delete a file it appears as a missing file in git. And Code shows it as deleted. But it's not staged. Yet, Code is nice as still lets you commit that without staging as well.

When you move a file, it appears as a delete and an add in git. And Code shows it as an add and a delete. This is because, similarly to the previous cases, it is not staged. Yet, Code is nice and still lets you commit that without staging. And it will appear in history as a rename.

[leegee]

That's nice. That's what I'm talking about. Probably quicker to implement it than write all those excuses above.

/Thank you/.