In some rebases, `exec git -C ...` has wrong working directory

In some rebases, `exec git -C ...` has wrong working directory

[William Chargin]

Here is a repro script:

    #!/bin/sh
    set -eux
    git --version
    tmpdir="$(mktemp -d)"
    cd "${tmpdir}"
    mkdir target repo
    cd repo
    git init
    touch file; git add file
    git commit -m "Initial commit"
    git rebase HEAD --exec "git -C ${tmpdir}/target init"

The end of this script prints something like

    Executing: git -C /tmp/tmp.gd2q51jO93/target init
    Reinitialized existing Git repository in /tmp/tmp.gd2q51jO93/repo/.git/
    Successfully rebased and updated refs/heads/master.

But this is wrong: the repository should be initialized in `target`, not
reinitialized in `repo`.

Notes:

  - This propagates to subprocesses: if you run `exec make test` and
    your test suite ends up calling `git -C`, then the same problem
    occurs.

  - Substituting `rebase --root` for `rebase HEAD` causes the problem to
    go away.

  - The `rebase HEAD` exec context adds the `GIT_DIR` environment
    variable, and this is sufficient to reproduce the problem:
    running `GIT_DIR="$PWD" git -C /tmp/target init` puts the repo in
    the current working directory. The `rebase --root` context adds no
    such environment variable. (You can use `--exec 'env >tempfile'` to
    verify these.)

My `git --version` is 2.16.2.

Re: In some rebases, `exec git -C ...` has wrong working directory

[Johannes Schindelin]

Hi William,

On Thu, 26 Apr 2018, William Chargin wrote:

> Here is a repro script:
> 
>     #!/bin/sh
>     set -eux
>     git --version
>     tmpdir="$(mktemp -d)"
>     cd "${tmpdir}"
>     mkdir target repo
>     cd repo
>     git init
>     touch file; git add file
>     git commit -m "Initial commit"
>     git rebase HEAD --exec "git -C ${tmpdir}/target init"

We do take pains to pass the GIT_DIR to the exec'ed command, and it is the
GIT_DIR of the worktree in which the rebase runs.

> The end of this script prints something like
> 
>     Executing: git -C /tmp/tmp.gd2q51jO93/target init
>     Reinitialized existing Git repository in /tmp/tmp.gd2q51jO93/repo/.git/
>     Successfully rebased and updated refs/heads/master.

So that is actually what I expected.

I might even have one or two scripts relying on that feature, where
something like

	exec git -C /somewhere/else show HEAD:some-file >some-other-file

is executed, and works.

> But this is wrong: the repository should be initialized in `target`, not
> reinitialized in `repo`.
> 
> Notes:
> 
>   - This propagates to subprocesses: if you run `exec make test` and
>     your test suite ends up calling `git -C`, then the same problem
>     occurs.
> 
>   - Substituting `rebase --root` for `rebase HEAD` causes the problem to
>     go away.
> 
>   - The `rebase HEAD` exec context adds the `GIT_DIR` environment
>     variable, and this is sufficient to reproduce the problem:
>     running `GIT_DIR="$PWD" git -C /tmp/target init` puts the repo in
>     the current working directory. The `rebase --root` context adds no
>     such environment variable. (You can use `--exec 'env >tempfile'` to
>     verify these.)
> 
> My `git --version` is 2.16.2.

Even `pu` has the same behavior.

I do not think that we can sensibly *remove* GIT_DIR from the environment
variables passed to the exec'ed command, as we have been doing that for
ages, and some scripts (as demonstrated above) started relying on that
behavior. So if we changed it, we would break backwards-compatibility,
which is something we try to avoid very much in Git.

Maybe you could a contribute a patch to the documentation? Something that
tells people who use the `--exec` option that they want to prefix their
command with `unset GIT_DIR; ` when their command wants to work with a
different Git repository than the current one?

Ciao,
Johannes

Re: In some rebases, `exec git -C ...` has wrong working directory

[William Chargin]

Hi Johannes,

Thanks for your reply.

Part of my confusion was regarding the interaction between `-C` and
`--git-dir`. For instance, we have

    $ git --git-dir target -C /tmp/tmp.Cl4aXMSVis init
    Initialized empty Git repository in /tmp/tmp.Cl4aXMSVis/target/

which makes sense and is what I expected: the `-C` and `--git-dir`
values are joined, as suggested by the docs for `-C` in git(1). But with

    $ git --git-dir /tmp/tmp.Cl4aXMSVis/repo -C /tmp/tmp.Cl4aXMSVis init
    Initialized empty Git repository in /tmp/tmp.Cl4aXMSVis/repo/

it appears that the `-C` argument is ignored entirely. Is this because
running `git -C foo ...` is equivalent to running `cd foo; git ...` in a
shell, so when the `--git-dir` is an absolute path the value of `-C` has
no effect? (Assuming that `GIT_WORK_TREE` is unset.)

In your example:

>        exec git -C /somewhere/else show HEAD:some-file >some-other-file

isn't the behavior to copy the version of `some-file` in the repository
being rebased to `some-other-file` in the current working directory,
such that the `-C` has no effect, because the shell redirect is not
affected by the `-C`? (This is what happens for me.) If so, why include
the `-C` in the command?

> I do not think that we can sensibly *remove* GIT_DIR from the environment
> variables passed to the exec'ed command, as we have been doing that for
> ages, and some scripts (as demonstrated above) started relying on that
> behavior. So if we changed it, we would break backwards-compatibility,
> which is something we try to avoid very much in Git.

This makes sense; understood and agreed.

Do you know why `rebase --root` does not set `GIT_DIR`?

> Maybe you could a contribute a patch to the documentation?

Sure; I'd be happy to do that once I understand this a bit better. :-)

Best,
WC