On Tue, Mar 29, 2016 at 12:56:41PM -0700, Junio C Hamano wrote:
> >> So it is a misconfiguration if you only set GIT_WORK_TREE without
> >> setting GIT_DIR.
> >
> > Hmm. I have frequently done this when my cwd is a git repository (e.g.,
> > a bare one), and it works as you'd expect (find the git-dir in the
> > current path, then the working tree via $GIT_WORK_TREE).
>
> Hmm, does what is done by "git add HEAD" in such a situation match
> what you'd expect?
>
> git init work
> cd work; date >HEAD; git commit -m initial
> git push ../bare master:master
> date >>HEAD
> export GIT_WORK_TREE=$(pwd)
> cd ..
> git --bare init bare
> cd bare
> git add HEAD
I had to tweak your commands a little, but I assume the part you are
interested in is the end, when git-add finds HEAD in $GIT_WORK_TREE and
not the bare repository.
And yes, that is exactly what I'd expect, and why it is useful (if you
wanted to add arbitrary cruft from the bare repo, you'd set
$GIT_WORK_TREE to point there).
> I'd have to say that this invites unnecessary confusion, even though
> I agree that "go to the GIT_WORK_TREE and take pathspecs relative to
> that directory" is the only sensible thing for us to be doing.
>
> But that is not an issue about "set only work-tree" (it is about
> "run from outside the work-tree").
Yeah, there are two things going on:
1. Without $GIT_DIR but with $GIT_WORK_TREE, we find $GIT_DIR via the
usual discovery path.
2. When outside $GIT_WORK_TREE, any work-tree operations work as if
they were started from $GIT_WORK_TREE.
And relying on (1) almost always relies on (2), unless your work-tree
happens to be inside the discovery path for your $GIT_DIR. So you could
do:
git init repo
mkdir repo/subdir
echo content >file
GIT_WORK_TREE=$(pwd) git add .
which adds "file" at the top-level. And we used only rule (1), not rule
(2). I don't know whether people actually do that or not (I guess it
could be useful for tricky subtree things).
-Peff
--
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