From: "Junio C Hamano" <gitster@xxxxxxxxx>
worley@xxxxxxxxxxxx (Dale R. Worley) writes:
In general, Git commands on a repository with a detached worktree can
be executed by cd'ing into the directory containing the .git
directory, ...
Eh? News to me; it might happened to have appeared to work by
accident, but that is not by design.
I think it is this part in Dale's original email
"However, this approach does not work with "git filter-branch", which
objects with "You need to run this command from the toplevel of the
working tree."
that is the problem Dale has seen. IIRC there are a few commands that do
require to be run from the toplevel ('git bisect' I think is another),
and the detection process for 'toplevel' may not work properly when in a
separated work-tree environment.
Perhaps something to consider.
Philip
IIRC, the intended use pattern (i.e. the change that introduced
GIT_DIR and GIT_WORK_TREE environment variables was designed to
support) for such a working tree is to:
- export GIT_DIR that points at the correct .git directory;
- export GIT_WORK_TREE that points at the correct top-level of such
a working tree; and then
- run the commands anywhere in the working tree, as if you did not
export these two environment variables and instead had the .git
directory at the usual place in the working tree.
It _is_ possible that we may have broken this canonical use pattern
over time with more recent updates; I do not think we have extensive
test coverage for "detached worktree" use case in the first place.
Does anyone have any feedback on this?
Not exporting GIT_DIR variable in sh-setup was done not by accident
but as a very deliberate design choice, IIRC.
--
--
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