search

msysgit / git

msysGit-based Git for Windows 1.x is now superseded by Git for Windows 2.x
http://github.com/git-for-windows/git
Other
1.01k stars 317 forks source link

Removing remotes does not delete the folder in .git/refs/remotes #355

Closed mikeparker closed 9 years ago

mikeparker commented 9 years ago

This may not cause any issues, but I assume this should probably be gone on deletion?

I'm using the latest version (1.9.5)

linquize commented 9 years ago

Linux version of git also does not delete empty refs folder

NysItsFrgDougM commented 9 years ago

This does cause an issue, when you latter add a new remote with different capitalization. It's a filesystem-specific bug, too, since it only affects if the capitalization is different.

linquize commented 9 years ago

Yes, exactly. You also need to look at .git/packed-refs and see if casing differs from loose ref directories .git/refs/remotes/.

dscho commented 9 years ago

Wait a moment. How does an empty .git/refs/remotes/ directory (all lower-case) affect remotes whose names differ in case from previous ones'? Unless you say that empty subdirectories of .git/refs/remotes/ are left behind, I don't get it.

NysItsFrgDougM commented 9 years ago

Please re-open.

Yes, it's a subfolder of .git/refs/remotes/

On Windows NTFS:

1: Add a "Doug" remote and do a fetch. the .git/refs/remotes/Doug folder is created.

2: Remote the "Doug" remote. The ".git/refs/remotes/Doug" folder remains.

3: Add a new "doug" remote; a ".git/refs/remotes/doug" folder is not created, since NTFS treats it as ".git/refs/remotes/Doug"

4: User is now unable to fetch / manage their remotes.

From: dscho notifications@github.com Sent: Saturday, August 22, 2015 12:29 PM To: msysgit/git Cc: Meerschaert, Douglas (ITS) Subject: Re: [git] Removing remotes does not delete the folder in .git/refs/remotes (#355)

Closed #355https://github.com/msysgit/git/issues/355.

Reply to this email directly or view it on GitHubhttps://github.com/msysgit/git/issues/355#event-389550012.

dscho commented 9 years ago

You sure took your time to respond.

Now that the symptom is established, it is also clear that this is a case-insensitive file system issue, i.e. a bug in upstream Git. Please report it on the Git mailing list: git@vger.kernel.org