Re: [PATCH v3 13/39] i18n: git-sh-setup.sh: mark strings for translation
From: Junio C Hamano <hidden>
Date: 2016-06-16 02:19:41
Vasco Almeida [off-list ref] writes:
Positional arguments, such as $0, $1, etc, need to be stored on shell variables for use in translatable strings, according to gettext manual [1]. Add git-sh-setup.sh to LOCALIZED_SH variable in Makefile to enable extraction of string marked for translation by xgettext. Although git-sh-setup.sh is a shell library to be sourced by other shell scripts, it is necessary to source git-sh-i18n at this point, because some scripts don't do it themselves. Not sourcing git-sh-i18n would lead to failure due to, for instance, gettextln not being found.
That is correct, but doesn't that hint that the current users of git-sh-i18n no longer have to (and they probably do not want to) dot-source it, as they are already dot-sourcing git-sh-setup? Otherwise they will waste cycles reading the same thing twice (assuming that git-sh-i18n is safely read twice, that is).
Source "$(git --exec-path)"/git-sh-i18n instead of simply git-sh-i18n,
That is somewhat strange. "git-rebase.sh" dot-sources both git-sh-setup and git-sh-i18n with just ". $name". What is so special about sh-setup dot-sourcing sh-i18n your patch adds?
because latter case would fail test t2300-cd-to-toplevel.sh.
What is the real cause of this? ". git-sh-setup" is supposed to work because we prepend the $GIT_EXEC_PATH in "git" itself and git-sh-setup is installed there. ". git-sh-i18n" in "git-rebase.sh" works the same way. If it is because is t2300 doing something strange, then we should fix that, not adding $(git --exec-path) on the dot-source line to paper things over.