> 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 must admit I've never seen the design (and I personally doubt that
the design has ever been written down). But at least the following
commands work correctly on a detached worktree if the current
directory contains the .git directory, because I am using them in a
production manner:
git add
git cat-file
git commit
git commit-tree
git config
git gc
git log
git ls-tree
git reset
git rev-list
git update-ref
In my situation, the worktree is not, in my mind, dependent on the
repository; the repository is intended to keep backups of the contents
of the directories that are worktree. Indeed, one could establish
several detached repositories to back up different subsets of the same
worktree. So it is conceptually natural to execute Git in the
repository directory. And, after all, the current directory
identifies the repository and the repository contains a pointer to the
worktree.
> Not exporting GIT_DIR variable in sh-setup was done not by accident
> but as a very deliberate design choice, IIRC.
The intention of my change is that it appears that all of the failures
of my use pattern are when the command is implemented by a shell
script, and it appears that all shell scripts initially invoke
git-sh-setup.
The change specifically detects my use pattern and, for the remainder
of the script, changes the use pattern into a pattern closely related
to the one that Junio documents:
- export GIT_DIR that points at the correct .git directory;
- GIT_WORK_TREE is left unset
- set the current directory to the top of the working tree
Perhaps the change should also set GIT_WORK_TREE. I haven't noticed
setting GIT_WORK_TREE to be necessary for "git filter-branch", but
perhaps that is coincidental.
It seems to me that this change would uniformly support the use
pattern I use without affecting Git's behavior in any other case.
Dale
--
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