Character normalization bug

[joshbetz]

There seems to be a normalization bug in the Status() function. I put together a gist to demonstrate the issue.

git clone https://gist.github.com/joshbetz/fe8d6af45f7801c1f4e96e1cc41b5062
cd fe8d6af45f7801c1f4e96e1cc41b5062
go run main.go

If you run git status after that, you'll see there's a new file with a different name, though it's rendered as the same character as another filename that already exists.

https://en.wikipedia.org/wiki/Unicode_equivalence#Normalization

[mcuadros]

git:master@fe8d6af45f7801c1f4e96e1cc41b5062> go run main.go
git:master@fe8d6af45f7801c1f4e96e1cc41b5062> code main.go
git:master@fe8d6af45f7801c1f4e96e1cc41b5062> git status   
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

[joshbetz]

Interesting. I get:

$ go version
go version go1.8 darwin/amd64
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
$ go run main.go
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   "\341\204\221\341\205\246"

[mcuadros]

wow, this is very weird, maybe is related with macOS?

go version go1.8.3 linux/amd64

[joshbetz]

Seems like it might be related. I'm doing some testing.

[mcuadros]

https://stackoverflow.com/questions/13089582/os-x-how-to-calculate-normalized-file-name

[joshbetz]

I think we'd need to use something like https://godoc.org/golang.org/x/text/unicode/norm to detect equivalent filenames.