Potential Same Name Bug

Kevin Smith· Sep 12, 2016, 23:29 UTC · lore

I hit an issue in Git today that seemed to be a bug. Basically what happened is in our master branch we had two files, one named something like "file_NAME.png" and another named "file_name.png" in the same folder. In the develop branch in the same repo we had removed the "file_NAME.png" file so that only the "file_name.png" file was left. If I clone the repo so I get master and then do "git checkout develop" I would see when running "git status" that I would have this message:

On branch develop
Your branch is up-to-date with 'origin/develop'.
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    file_name.png

no changes added to commit (use "git add" and/or "git commit -a")

So when I move from master to develop that status would come up. If I ran "git reset --hard" I would no longer have that message. I also saw that when I do a git clone and specify to clone the develop branch that I would not see the git status above. Is this an issue where if one branch has two files of the same name where one gets removed that it will remove both instances of that file in another branch when you switch to it? I fixed this issue in our repo by removing the "file_NAME.png" file in the master branch, but it seems like this should be handled better in the case I described.

Andrew Ardill· Sep 13, 2016, 00:35 UTC · re: Kevin Smith · lore

Re: Potential Same Name Bug

Hi Kevin,

On 13 September 2016 at 09:29, Kevin Smith <noiz77@gmail.com> wrote:

Show 9 quoted lines

> So when I move from master to develop that status would come up.  If I
> ran "git reset --hard" I would no longer have that message.  I also
> saw that when I do a git clone and specify to clone the develop branch
> that I would not see the git status above.  Is this an issue where if
> one branch has two files of the same name where one gets removed that
> it will remove both instances of that file in another branch when you
> switch to it?  I fixed this issue in our repo by removing the
> "file_NAME.png" file in the master branch, but it seems like this
> should be handled better in the case I described.

Just to clarify, is the machine you are cloning to on a case-insensitive file system, or have you set core.ignorecase=true?

If so, I would imagine the behaviour would have been _interesting_ in that repository before you removed one of the versions - that may be why you removed it in the first place.

For future reference, the typical way I have seen this situation dealt with is to git mv one file to a different filename, or using git rm. There may be better ways to do it, and it's possible git should deal with the specific situation you mentioned better, but I'm not able to comment on that.

This situation commonly arises when you set core.ignorecase=false on a case insensitive file system and then rename a file. When you commit that change, git doesn't notice that the old filename has been 'deleted' (git sees a rename as a delete+create with the same file contents) and so now thinks that you have two files with very similar names in your working directory. To avoid this, make sure core.ignorecase is set correctly, and use git mv -f to rename files on case insensitive file systems.

Details at https://stackoverflow.com/questions/17683458/how-do-i-commit-case-sensitive-only-filename-changes-in-git

Regards,

Andrew Ardill