From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 11 Apr 2011 19:15:13 GMT
Subject: Re: [PATCH 8/8] gitk: show modified files with separate work tree
Message-ID: <7vipukwqf2.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110410020318.GB25368@brick.ozlabs.ibm.com>

Paul Mackerras <paulus@samba.org> writes:

>> Why do git commands that need a work tree not work under .git?
> ...
> Don't know, ask Junio. :)

Whatever the current behaviour is, I am reasonably sure that it is coming
more from "meh -- who cares such a case?" than "it should work like this
when you are in .git because of such and such reasons".

For example, what does it mean to be able to do this?

	$ edit Makefile
        $ git add Makefile
        $ edit Makefile
	$ cd .git
        $ git grep frotz Makefile

Perhaps the last step needs to be

	$ git grep frotz ../Makefile

instead, but a more important point is, how would that be useful?

If you have both GIT_DIR and GIT_WORK_TREE set up to point at the correct
places, I think it is sensible to make the above (the "../Makefile"
version, not the one without dot-dot) work as expected.

I suspect (but would not bother to dig the history myself to find out)
that "we require a working tree" semantics that in fact often means "we
require you to be in the working tree" was a misdesign that did not matter
that came from the days back when GIT_WORK_TREE was not either present or
not widely used.  Now more people seem to be using GIT_WORK_TREE for some
reason, I don't have anything against a patch series that defines and
implements a more desirable behaviour clearly.

Thanks.