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
