Thomas Rast <tr@xxxxxxxxxxxxx> writes:
> The problem here is that shell scripts that want to do something with a
> worktree tend to call require_work_tree in git-sh-setup:
>
> require_work_tree () {
> test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = true ||
> die "fatal: $0 cannot be used without a working tree."
> }
>
> However, when an explicit GIT_WORK_TREE is in effect, that seems a bit
> silly. The _intent_ of that command is "I need a worktree to work
> with". But what it currently checks is something completely different,
> namely "am I _inside_ the worktree".
Correct.
I have a few issues with the proposed "solution", though.
- require_work_tree has always meant that "This command has to be
run inside a working tree". That automatically implies that you
cannot be working with a bare repository but it is much stronger
than that. You actually have to be inside one.
- $GIT_WORK_TREE (and core.worktree) never meant "I do not bother
to chdir there myself". More specifically, "GIT_WORK_TREE=$there
git foo" is not "cd $there && git foo". It only means "Because
the working tree may not have .git directory embedded in it, even
though you may be able to know where the .git repository is
(perhaps because I am telling you with $GIT_DIR), you may not be
able to tell where the top level of the working tree is---hence I
am telling you where it is".
- "I do not bother to chdir there myself" has long been treated as
a non-issue desire, but recently we added "git -C $there". We
should not conflate GIT_WORK_TREE, which is a discovery mechanism
for where the working tree is, with that.
- Some command "git foo" may want to affect and/or look at only a
part of the working tree, and the $cwd is one way of specifying
that, e.g. "cd doc && git grep foo". "If a command that needs to
be run from somewhere in a working tree was run outside, error
out." has been the general design principle for commands that
interact with files in the working tree.
It may be OK to propose changing it to "Instead of erroring out,
pretend as if the command were run from the top-level of the
working tree", but there is an issue of what to do with the
command line arguments that are path-like. For example,
should this command sequence:
cd /tmp
GIT_WORK_TREE=/var/tmp/work git foo -f inputFile
read from /tmp/inputFile, or /var/tmp/work/inputFile? There may
be other "unintuitive interactions with silent chdir"; with "git
-C $there", we are very clear that chdir is the first thing that
happens and everything path-like are relative to $there, which is
similar to what "make" does, but doing the same for core.worktree
or $GIT_WORK_TREE may be surprising, given that environment is
"set and forget" (the examples in this message explicitly spell
it out with one-shot export syntax, but that is only for
illustration) and not visible during usual use of the commands.
> But it would give require_work_tree somewhat interesting and unintuitive
> side effects.
Exactly. My knee-jerk reaction is that I do not think we would want
to go there, but I haven't thought things through.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html