Re: [Bug] git pull doesn't recognize --work-tree parameter

From: Jeff King <peff@peff.net>
Date: Oct 13, 2011, 19:14 UTC
Message-ID: <20111013191457.GA18460@sigill.intra.peff.net>
In-Reply-To: <7v62js4sop.fsf@alter.siamese.dyndns.org>

On Thu, Oct 13, 2011 at 12:06:46PM -0700, Junio C Hamano wrote:

Show 7 quoted lines

> It is not as simple as that I am afraid. We could introduce cd_to_top with
> the new semantics and use it in pull and rebase, but a case that would
> break is for a script (let's call that hypothetical operation "git svn
> dcommit", even though I do not know if dcommit uses the real working tree
> or a temporary one) that prepares a temporary working tree inside .git/svn/
> and run "git rebase" there without setting GIT_WORKING_TREE to point at
> the temporary directory.

I didn't think that could happen now, because you would not be in the working tree, and therefore require_work_tree would fail. E.g., with current git I get:

  $ mkdir .git/tmp
  $ cd .git/tmp
  $ git rebase
  fatal: fatal: /home/peff/local/git/private/libexec/git-core/git-rebase
  cannot be used without a working tree.

So that case is already broken. The only change this would make is that what used to fail would not actually take them to the top-level of the working tree[1].

-Peff

[1] Actually, I am not sure it would do that. If we are in $GIT_DIR, do we necessarily know where the working tree is? I guess in a non-bare repo, we assume it is $GIT_DIR/..?