git submodule add broken (2.11.0-rc1): Cannot open git-sh-i18n

Noticed as part of my automated tests here: https://travis-ci.org/pre-commit/pre-commit/jobs/173957051

Minimal reproduction:

rm -rf /tmp/git /tmp/foo /tmp/bar git clone git://github.com/git/git --depth 1 /tmp/git pushd /tmp/git make -j 8 popd export PATH="/tmp/git:$PATH" git init /tmp/foo git init /tmp/bar cd /tmp/foo git submodule add /tmp/bar baz

Output:

$ rm -rf /tmp/git /tmp/foo /tmp/bar $ git clone git://github.com/git/git --depth 1 /tmp/git Cloning into '/tmp/git'... remote: Counting objects: 3074, done. remote: Compressing objects: 100% (2735/2735), done. remote: Total 3074 (delta 249), reused 1871 (delta 215), pack-reused 0 Receiving objects: 100% (3074/3074), 6.38 MiB | 905.00 KiB/s, done. Resolving deltas: 100% (249/249), done. Checking connectivity... done. $ pushd /tmp/git /tmp/git /tmp $ make -j 8 GIT_VERSION = 2.11.0-rc0

... lots of make output ...

$ popd /tmp $ export PATH="/tmp/git:$PATH" $ git init /tmp/foo warning: templates not found /home/asottile/share/git-core/templates Initialized empty Git repository in /tmp/foo/.git/ $ git init /tmp/bar warning: templates not found /home/asottile/share/git-core/templates Initialized empty Git repository in /tmp/bar/.git/ $ cd /tmp/foo $ git submodule add /tmp/bar baz /tmp/git/git-submodule: 46: .: Can't open /home/asottile/libexec/git-core/git-sh-i18n $ echo $? 2

Thanks

Anthony

    $ git --version
    git version 1.8.5.6
    $ if [ "$LATEST_GIT" = "1" ]; then
    ...
         export PATH="/tmp/git:$PATH"
     fi
    ....
    make -j 8
    ...
    $ git --version
    git version 2.11.0-rc0

So you compile 2.11.0-rc0 yourself, but you do not install it, instead the $PATH is pointed to /tmp/git instead, however the later calls fail with:

    Can't open /home/travis/libexec/git-core/git-sh-i18n

which is where 1.8.5.6 is installed.

So you're running into an internationalization problem between 2 very different versions of Git (1.8 seems to be ancient)

Not sure if i can offer advice except from "Don't do that, instead install Git properly". ;)

Thanks, Stefan

On Mon, Nov 7, 2016 at 10:30 AM, Anthony Sottile <asottile@umich.edu> wrote:

(Just guessing myself:)

$ git log --grep git-sh-i18n v2.10.0..v2.11.0-rc0
commit da14d73d5eacfb2fa9d054f94d9eecb2244c3ce5
Merge: 2f445c17e5 1073094f30
Author: Junio C Hamano <gitster@pobox.com>
Date:   Mon Oct 31 13:15:25 2016 -0700

    Merge branch 'ak/sh-setup-dot-source-i18n-fix'

    Recent update to git-sh-setup (a library of shell functions that
    are used by our in-tree scripted Porcelain commands) included
    another shell library git-sh-i18n without specifying where it is,
    relying on the $PATH.  This has been fixed to be more explicit by
    prefixing $(git --exec-path) output in front.

    * ak/sh-setup-dot-source-i18n-fix:
      git-sh-setup: be explicit where to dot-source git-sh-i18n from.

commit 1073094f30a8dd5ae49f2146f587085c4fe86410
Author: Anders Kaseorg <andersk@mit.edu>
Date:   Sat Oct 29 22:10:02 2016 -0400

    git-sh-setup: be explicit where to dot-source git-sh-i18n from.

    d323c6b641 ("i18n: git-sh-setup.sh: mark strings for translation",
    2016-06-17) started to dot-source git-sh-i18n shell script library,
    assuming that $PATH is already adjusted for our scripts, namely,
    $GIT_EXEC_PATH is at the beginning of $PATH.

    Old contrib scripts like contrib/convert-grafts-to-replace-refs.sh
    and contrib/rerere-train.sh and third-party scripts like guilt may
    however be using this as ". $(git --exec-path)/git-sh-setup",
    without satisfying that assumption.  Be more explicit by specifying
    its path prefixed with "$(git --exec-path)/". to be safe.

    While we’re here, move the sourcing of git-sh-i18n below the shell
    portability fixes.

    Signed-off-by: Anders Kaseorg <andersk@mit.edu>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

Stefan Beller <sbeller@google.com> writes:

Before that one since v2.10.0, there ie d323c6b641 that starts to include git-sh-i18n from git-sh-setup in the first place. If you are testing or using a newly-out-of-oven uninstalled Git, you would need to do these to be correctly using it:

 * Many subcommand executables and helpers are not installed on any
   directory on your $PATH, but are installed in GIT_EXEC_PATH.
   Find out where it is by asking the newly-out-of-oven Git "git
   --exec-path" without setting GIT_EXEC_PATH environment variable.
   That is where your newly built one wants to find things.

 * Because you are trying to use the newly-out-of-oven Git without
   installing, you do not want to install into the real
   GIT_EXEC_PATH location yet.  Pick a new empty directory and
   arrange the files that would be installed by our Makefile into
   "git --exec-path" if you did "make install" to be in this new
   location.  The set of files include git-sh-setup and git-sh-i18n.

 * Set and export GIT_EXEC_PATH to point at this new empty directory
   you just populated.

That incidentally is how we make our "make test" work.

If you only set $PATH to the top of git build directory, without doing the above arrangement with GIT_EXEC_PATH, things may have appeared to work due to multitude of accidents. Builtin commands would worked fine because it is just a single "git" binary after all, i.e. "git log" would not have consulted a "git-log" binary on anywhere in your filesystem. Other commands may have been run from the already installed version on the system. The latter is particularly problematic, because it means that one thought that one is testing the newly built on before installing to make sure that the new one works OK, but is actually testing the already installed one.