In his latest "What's cooking in git.git" message (Nov 2011, #2; Sun, 6)
J.C.Hamano announced the availability of the documentation
branches (html, doc) in dedicated repositories at github.com.
Change .gitmodules to point 'doc/git/html' to the new repository.
Signed-off-by: Stefan Naewe <firstname.lastname@example.org>
Signed-off-by: Pat Thoyts <email@example.com>
We avoid setting `encoding' and `termencoding', and opt to only setting
`fileencodings' because it's understood that vim sets the former two to
the user's system's "ANSI" and "OEM" code pages (setting either both if
they differ or only `encoding' if they're the same) . The setting of
"OEM" is particularly significant as it is required for native characters
to be correctly displayed on the user's console .
We set "utf-8" as the only value of `fileencodings', there by making it
the default encoding used to save new commit messages to COMMIT_EDITMSG.
This is consistent with what git expects in an environment where the
user has not altered the value of `i18n.commitencoding'.
When loading an existing message, for operations such as 'commit --amend'
and 'rebase -i', our setting for `fileencodings' means that vim will first
attempt to load it as UTF-8 and then fallback to the encoding set by
`encoding' if unable to do so. This encoding is expected to be "ANSI",
as mentioned above, and this side-effect is of benefit if the user does
have an altered value of `i18n.commitencoding'. (Here, we're assuming
users not set this, if at all, to anything other than that of "ANSI"
because that is thought to be the most natural for their location.)
Users SHOULD unset `i18n.commitencoding' after this is released. However,
failing to do so may not show any visible regressions. (See tests for
case #2 at .)
This patch follows the discussion in the  link.