yysun/Git-Source-Control-Provider

When I renamed "OptionChainListEOD" to "OptionChainListEod", it didn't recognize that the file had been changed, and didn't update the icons in Solution Explorer for VS2012.

Opened this issue · 5 comments

Deleted user commented

Hi,

First of all, Git Source Control Provider is absolute magic, and I use it every day. Thank you ever so much for writing it.

These changes are for VS2012.

If I modify "filename.cs" to "filename2.cs", it:

  1. Deletes "filename.cs".
  2. Add "filename1.cs".

This is the correct behavior.

However, if I modify "filename.cs" to "Filename.cs", doesn't recognize the modification. However, the icon in the "Solution Explorer" permanently changes to a "+" symbol, which makes me suspicious that the file is not under GIT source control.

So, I ended up with about 20 files in "Solution Explorer" with the "+" symbol for the icon, despite the fact that they were under GIT source control. The problem was caused by renaming a file so that "Eod" became "EOD":

bad

When I renamed "EOD" back to "Eod", the problem disappeared:

good

Summary:

If I make a minor rename to a file, such that the case of the filename changes (i.e. "EOD" becomes "Eod"), then you should:

  1. Delete the original file.
  2. Add a new file.

If you don't, then the icons in "Solution Explorer" do not update properly.

I think this problem is related to the fact that under Linux, filenames are case sensitive, whereas in Windows they are not.

Deleted user commented

Currently, the workaround for this is as follows:

If I want to rename "filename.cs" to "Filename.cs", I:

  1. Rename "filename.cs" to "filename1.cs".
  2. Check in.
  3. Rename "filename1.cs" to "Filename.cs".
  4. Check in.

If I simply rename "filename.cs" to "Filename.cs", then the icon in Solution Explorer permanently shows "+" which implies that its not under GIT source control (in fact, I believe it is).

sharwell commented

I cannot reproduce this issue in the latest working builds. If this issue appears for you again after the next release, please reopen this issue.

Deleted user commented

Hi,

Thank you for investigating this.

I just reproduced the error on a completely fresh GIT repository (so it's
probably not related to the change to Unicode encoding from GIT v1.7.1
onwards).

I renamed the file "Class1.cs" to "ClaSS1.cs", and GIT source control
provider doesn't mark it is "Changed" in the "Git Pending Changes".

My versions:

  * > git --version
       git version 1.8.0.msysgit.0
  * Git Source Control Provider: v1.0.0.
  * Visual Studio 2012.

If the error reappears again after the next release, I'll reopen the issue.
In the meantime, I can work around it by deleting the file manually, then
readding it.

On Sat, Feb 9, 2013 at 4:04 AM, Sam Harwell notifications@github.comwrote:

I cannot reproduce this issue in the latest working builds. If this issue
appears for you again after the next release, please reopen this issue.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-13325958..

sharwell commented

The Git Source Control Provider won't mark it as changed in the case you listed above, because git.exe on Windows does not report that the file changed. The expected behavior of this plugin for the case you describe is to continue to report that the file is up-to-date (glyph looks like a padlock).

Git Extensions, git.exe in cygwin, and Git Source Control Provider all produce the same results (changing only the case of a file name is not detected as any form of actual change).

Deleted user commented

Thank you for your feedback. The glyph in my build configuration definitely
turns from a padlock into a "+" symbol.

I suspect that its probably because I'm using msysgit 1.8.0.

I should also add that my system is WIndows 7 x64.

This is a minor error; most users eventually work around it by just
deleting/readding the file.

On Sat, Feb 9, 2013 at 11:20 PM, Sam Harwell notifications@github.comwrote:

The Git Source Control Provider won't mark it as changed in the case you
listed above, because git.exe on Windows does not report that the file
changed. The expected behavior of this plugin for the case you describe is
to continue to report that the file is up-to-date (glyph looks like a
padlock).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-13340828..