Re: Dropping core.worktree and GIT_WORK_TREE support

From: Miklos Vajna <vmiklos@frugalware.org>
Date: Aug 25, 2008, 12:52 UTC
Message-ID: <20080825125205.GB23800@genesis.frugalware.org>
In-Reply-To: <7v1w0dkd5s.fsf@gitster.siamese.dyndns.org>

On Sun, Aug 24, 2008 at 08:05:03PM -0700, Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

> > 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:

1) save the current directory, change to /some/other, execute git, and
change the directory back

2) use git --work-tree / --git-dir

I guess the second form is more elegant. Of course if it is decided that this option will be removed then the old form can be still used, but I think that would be a step back.

Show 17 quoted lines

> > Also, here is a question:
> >
> > $ git --git-dir git/.git --work-tree git diff --stat|tail -n 1
> >  1443 files changed, 0 insertions(+), 299668 deletions(-)
> >
> > So, it's like it thinks every file is removed.
> >
> > But then:
> >
> > $ cd git
> > $ git diff --stat|wc -l
> > 0
> >
> > is this a bug, or a user error?
> 
> I  think it is among the many other things that falls into "the two
> attempts still haven't resolved" category.

I'm unfamiliar with this part of the codebase, so in case somebody other could look at it, that would be great, but I'm happy with write a testcase for it. (Or in case nobody cares, I can try to fix it, but that may take a bit more time.)