Is git ls-files really character agnostic? If not, what is?

I’m working in Mac OS 10.6 with git version 1.7.0 .

If I execute

  • Conditional space in PS1
  • Sync GitHub repository with local directory
  • Can not clone git repo to server
  • Capistrano and Git, Ruining my life. “Unable to resolve revision for on repository …”
  • Visual Studio: View full git commit history (including renames)
  • Git missing code after merge
  • echo "" > frëd   # that's f r \xEB d
    git ls-files --other 'f*'

    I get back

    "fre\314\210d"                     # that's 14 characters including two \'s

    whereas ls f* reports

    frëd                               # 4 characters, 5 bytes

    This causes poor behaviour in magit-status mode in Emacs.

    How can I work around this and have git ls-files report the same way
    that ls does, without interpreting the bytes of the filename?

    — David

  • xcode, error when commiting to github repository
  • Setting up MAMP with git repo and virtual hosts
  • Are git forks actually git clones?
  • Problems when pulling git changes: uncommitted changes
  • git commit --amend is dangerous
  • How to use java git for java project
  • One Solution collect form web for “Is git ls-files really character agnostic? If not, what is?”

    Git escapes the filename so that it doesn’t contain any hard to interpret characters like terminal sequences, common separators like newline, etc. So does (gnu) ls by the way, but here ls is more tolerant. You can use the -z flag to get the original names in a zero-terminated, machine-parsable format. Magit should use it (parsing escapes is more fragile), patch it if you can.

    Git Baby is a git and github fan, let's start git clone.