From: "Philip Oakley" <philipoakley@xxxxxxx>
From: "Junio C Hamano" <gitster@xxxxxxxxx>
"Philip Oakley" <philipoakley@xxxxxxx> writes:
From: "Junio C Hamano" <gitster@xxxxxxxxx>
"Philip Oakley" <philipoakley@xxxxxxx> writes:
... and the detection process for 'toplevel' may not work
properly when in a separated work-tree environment.
Without GIT_WORK_TREE exported to point at the top-level, there is
nothing that lets us "detect" it, as the working tree does not have
".git" directory to tell us to stop, no?
"No", but not in that way.
My point (to Dale) was, as you state, that the "cd to top level" was
(IIUC) the probable causes of the fault, and that a documentation
update would probably be appropriate for the discussion on exporting
GIT_WORK_TREE, and that it would specifically mention those git
commands that needed to "cd to top level", and hence would not work
in
such an environment. (I wasn't sure where the appropriate "cd to top
level" function was)
An explanation here on the list wouldn't solve the problems for
others
who are yet to make the same mistake, hence the implied suggestion.
I understand what you mean by these last two lines. It was unclear
to me which part of our documentation needs updating and how, and
that was (and still is) what I was primarily interested in finding
out.
I was expecting that the places would be in git(1) [git.txt] and
config(1) [config.txt], in the enironment variables GIT_WORK_TREE
section and core.worktree sections repectively. However what the right
text would be hasn't been fully determined yet, as it should be clear
about which commands don't follow the stated 'rules'. Dale's use case
does appear to be stretching...
Philip
A bit more looking gave that the cd_to_toplevel () in git-sh-setup.sh
directly uses `git rev-parse --show-toplevel`, which simply returns
work_tree (static char *work_tree; in environment.c, with comment /*
This is set by setup_git_dir_gently() and/or git_default_config() */),
apparently without a check for the GIT_WORK_TREE.
One option may be to either protect the cd_to_toplevel code with a
check of `git rev-parse --local-env-vars` to see if GIT_WORK_TREE is
present. Or create `git rev-parse --work-dir` to match `--git-dir`. This
would be a code level fix. This makes the assumption that if a deteched
GIT_WORK_TREE is set then it is the top level.
In terms of command scripts that use git-sh-setup.sh we have a longish
list, so a full list in the documentation is probably unreasonable
(which suggests that a code fix would be more apprpriate)
commands:
git-am
git-bisect
git-filter-branch
git-instaweb
git-lost-found
git-merge-one-file
git-mergetool
git-pull
git-quiltimport
git-rebase
git-repack
git-request-pull
git-stash
git-submodule
git-web--browse
git\contrib\*various*
Philip
--
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