Re: Dropping core.worktree and GIT_WORK_TREE support
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 25, 2008, 21:21 UTC
- Message-ID
- <7vk5e4g58t.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <20080825125205.GB23800@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
Show 18 quoted lines
> On Sun, Aug 24, 2008 at 08:05:03PM -0700, Junio C Hamano <gitster@pobox.com> wrote: >> > Does this include removing of --work-tree as well? >> > >> > The git backend of Pootle (http://translate.sourceforge.net/wiki/) uses >> > it. >> >> Interesting. Does it use it because it can (meaning, --work-tree is >> supposed to work), or because --work-tree is the cleanest way to do what >> it wants to do (if the feature worked properly, that is, which is not the >> case)? > > It's like: > > The current working directory is like > /usr/lib/python2.5/site-packages/Pootle. The git repository is under > /some/other/path/outside/usr. > > Then Pootle has two possibilities:
The real question was about if/why that git repository _has to be_ outside of /usr/lib/*/Pootle/. Is that because --work-tree, if worked properly, would have allowed it to be, or is that because for some external reason you are not allowed to have .git under /usr/lib/*/Pootle/ directory?
If the latter, that shows the real requirement to keep supporting it as a feature, and issues around it need to be fixed. Otherwise, i.e. if it does not require use of --work-tree but it uses it only because it could, that gives us less incentive to keep --work-tree as a feature.
I haven't read the breakage and fix around diff in this thread yet, but I will when I get home.
Thanks to both Nguyen and you for trying to salvage --work-tree support.