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