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

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

[Anthony Sottile]

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

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

[Stefan Beller]

    $ 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

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

[Stefan Beller]

On Mon, Nov 7, 2016 at 10:30 AM, Anthony Sottile <asottile@umich.edu> wrote:
> This has worked great up until now (and is very convenient for trying things
> out without blowing away the system installation).  What changed?
>

(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>

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

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> On Mon, Nov 7, 2016 at 10:30 AM, Anthony Sottile <asottile@umich.edu> wrote:
>> This has worked great up until now (and is very convenient for trying things
>> out without blowing away the system installation).  What changed?
>>
>
> (Just guessing myself:)
>
> $ git log --grep git-sh-i18n v2.10.0..v2.11.0-rc0
> ...
> 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.
> ...

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.