This is pretty vague. What do you expect exactly?
I'm not a git user, so any detail is welcome.
Thanks.
--------------------------------------------------------------------------------
There is config option _i18n.logOutputEncoding_ (per repository) in git which stores encoding for log output with git-log.

From http://www.kernel.org/pub/software/scm/git/docs/git-config.html
<pre>
i18n.logOutputEncoding
Character encoding the commit messages are converted to when running git-log and friends.
</pre>

if it is empty or unset, then output will be UTF-8 encoded
else value specified in this option will be used

you can get this value with `git config i18n.logOutputEncoding`
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Additional reference.
http://www.kernel.org/pub/software/scm/git/docs/git-commit-tree.html
--------------------------------------------------------------------------------
Additional reference.
http://www.kernel.org/pub/software/scm/git/docs/git.html
> -c <name>=<value>
>
> Pass a configuration parameter to the command. The value given will override values from configuration files. The <name> is expected in the same format as listed by git config (subkeys separated by dots).

--------------------------------------------------------------------------------
I wrote "an answer":http://www.redmine.org/boards/2/topics/8829?r=21998#message-21998 to Weverton Morais about how I patched a problem we had i beleive is related to this ticket. I maintain a modified linux kernel git repo, so lots of international names in there, I narrowed it down to a simple duplicating scenario.

Try making a dummy git commit with this name:
<pre>
git commit -am"dummy test character encoding" --allow-empty --author="blaŻbla <tata@toto.com>"
</pre>

Then do the changeset fetch, I use
<pre>
ruby script/runner "Repository.fetch_changesets"
</pre>
or the /sys/fetch_changesets with the key.

The logs will show a collation error on a query. We use git under linux platforms and never worried about encoding, so I believe our platforms default to utf8.

As my answer said, the problem seemed to be that all of the tables created by redmine (or TurnKey Linux? the base of our install.) were defaulted to latin1. In any case, the fetch_chagesets code should acount for the difference in encoding if needed.
--------------------------------------------------------------------------------
... so the point is, it's not just the file paths inside the repo, or the commit logs, but all text contained within the repo it seems.
--------------------------------------------------------------------------------
Jean-François Dagenais wrote:
> ... so the point is, it's not just the file paths inside the repo, or the commit logs, but all text contained within the repo it seems.

According to docs this is false: i18n.commitencoding relates only to _log message_, all other parts should be treated as uninterpreted sequences of non-NUL bytes (file paths, author, commiter and other commit object headers).
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Implemented until r4964.
--------------------------------------------------------------------------------

relates,Closed,3196,Don't properly support encoding of repositories (git)
relates,Closed,1735,Per project repository log encoding setting
relates,Closed,5251,Git: Repository path encoding of non UTF-8 characters
relates,Closed,2664,Mercurial: Repository path encoding of non UTF-8 characters
relates,Closed,4773,Redmine+Git+PostgresSQL 8.4 fails with linux kernel tree (encoding)
relates,Closed,7597,Subversion and Mercurial log have the possibility to miss encoding