From: Philip Oakley Date: Wed, 16 Oct 2013 22:39:25 GMT Subject: Re: [git-users] Problem using detached worktrees with commands implemented in scripts Message-ID: <29AA597BEBC146B09E8B370949EC2CE9@PhilipOakley> In-Reply-To: From: "Junio C Hamano" > worley@alum.mit.edu (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. > --