On Tue, 2007-01-09 at 16:55 -0800, Junio C Hamano wrote:
> > That's not the use case for the -n option. Their case is what the
> > i18n.commitencoding configuration option exists for.
>
> I think you missed a subtle difference.
>
> For a project that is latin-1 only (or ISO-2022 only, for that
> matter -- 'only' is the real keyword here), users did not have
> to do anything, and happily kept using git, and that includes
> that they did not have to set i18n.commitencoding to anything.
Well, apart from the fact that gitweb and git-format-patch would be
mislabelling their output, for example.
> Defaulting to -u now means disrupt their established workflows
> are disrupted by people coming from UTF-8 only world. They now
> are forced to set i18n.commitencoding to latin-1 and/or use -n.
>
> When we inconvenience others by making changes to make our own
> life easier, it is not a good idea to insult them at the same
> time; rather, we should be asking forgiveness from them.
This is true. Sometimes when we fix bugs, we find that people were
relying on the old behaviour and are inconvenienced by the fix. That's
unfortunate, and we should make sure there's a simple way for those
people to adapt -- which in this case is setting 'i18n.commitencoding'.
I'm not entirely sure where the 'insulting' comes in though -- I think
you're referring to a comment which was
a) Only in my cover message rather than in the documentation, and
b) Not even relevant to these people -- these people should be
setting i18n.commitencoding to match their status quo, and my
disparaging comment was about the '-n' option which should be
avoided.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html