Potential Same Name Bug

Potential Same Name Bug

[Kevin Smith]

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.

Re: Potential Same Name Bug

[Andrew Ardill]

Hi Kevin,

On 13 September 2016 at 09:29, Kevin Smith <noiz77@gmail.com> wrote:
> 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