# Git stash (or git rev-parse) doesn't inherit the '--work-tree' parameter

2 messages from 2017-11-30 to 2017-12-04. Participants: marc PINHEDE, Jacob Keller.
Thread: https://gitlist.dev/t/47352

## marc PINHEDE, 2017-11-30 07:02

Subject: Git stash (or git rev-parse) doesn't inherit the '--work-tree' parameter
Message-ID: <CAJsT1ck6dCPLLMLjgq9jrQmOAC-6jF6kFEX6aaRJGw3Hn9He=w@mail.gmail.com>
URL: https://gitlist.dev/e/CAJsT1ck6dCPLLMLjgq9jrQmOAC-6jF6kFEX6aaRJGw3Hn9He%3Dw%40mail.gmail.com

```
Hello guys,

I don't know if this is a normal behavior, so I'll just explain it here.

* Behavior:

from a directory OUTSIDE my git repo, I can run this command successfully:
 $ git --git-dir=/my/repo/path/.git --work-tree=/my/repo/path pull origin master

But this one:
 $ git --git-dir=/my/repo/path/.git --work-tree=/my/repo/path stash
Will fails with :
 'fatal: $program_name cannot be used without a working tree.'
(Yes, the error message has been corrected since, but I use debian, so
I'm at least 6 month late).

* A bit of investigation:
I don't know many about git internal functioning, but with a bit of
googleing, I would point out git-sh-setup.sh:204, in function
require_work_tree, called by git-stash.
I could test (from outside my git repo, again):
 git --git-dir=/my/repo/path/.git --work-tree=/my/repo/path rev-parse
--is-inside-work-tree
return:
 false

What surprise me is that 'git-dir' seems to be passed ok to rev-parse:
 git --git-dir=/my/repo/path/.git --work-tree=/my/repo/path rev-parse --git-dir
returns:
 /my/repo/path/.git

* Question
Is this a normal behavior? Stash can only be applied in current
working directory?
If yes, I'll have to change my script to
 (cd && git command)
If not, should I push a bug report somewhere?

Marc

```

## Jacob Keller, 2017-12-04 10:55

Subject: Re: Git stash (or git rev-parse) doesn't inherit the '--work-tree' parameter
Message-ID: <70EAB5BC-F04B-475D-9F82-8CFDD7817C1F@gmail.com>
URL: https://gitlist.dev/e/70EAB5BC-F04B-475D-9F82-8CFDD7817C1F%40gmail.com
In-Reply-To: <CAJsT1ck6dCPLLMLjgq9jrQmOAC-6jF6kFEX6aaRJGw3Hn9He=w@mail.gmail.com>

```


On November 29, 2017 11:02:10 PM PST, marc PINHEDE <marc.pinhede@gmail.com> wrote:
>Hello guys,
>
>I don't know if this is a normal behavior, so I'll just explain it
>here.
>
>* Behavior:
>
>from a directory OUTSIDE my git repo, I can run this command
>successfully:
>$ git --git-dir=/my/repo/path/.git --work-tree=/my/repo/path pull
>origin master
>
>But this one:
> $ git --git-dir=/my/repo/path/.git --work-tree=/my/repo/path stash
>Will fails with :
> 'fatal: $program_name cannot be used without a working tree.'
>(Yes, the error message has been corrected since, but I use debian, so
>I'm at least 6 month late).
>
>* A bit of investigation:
>I don't know many about git internal functioning, but with a bit of
>googleing, I would point out git-sh-setup.sh:204, in function
>require_work_tree, called by git-stash.
>I could test (from outside my git repo, again):
> git --git-dir=/my/repo/path/.git --work-tree=/my/repo/path rev-parse
>--is-inside-work-tree
>return:
> false

It's possible that is-inside-worktree is testing if current dir is inside work tree, and not if the work tree variable is... Thus I wouldn't expect this to behave as you seem to expect.

>
>What surprise me is that 'git-dir' seems to be passed ok to rev-parse:
>git --git-dir=/my/repo/path/.git --work-tree=/my/repo/path rev-parse
>--git-dir
>returns:
> /my/repo/path/.git
>
>* Question
>Is this a normal behavior? Stash can only be applied in current
>working directory?
>If yes, I'll have to change my script to
> (cd && git command)
>If not, should I push a bug report somewhere?
>
>Marc


It doesn't sound like normal behavior to me... Does "git -C" work?

Either way id expect setting the work tree and got dir to work for most commands.

However, it may not of the command expects current dir to matter. That's where using -C comes into play. Try that and see if it fixes your problem.

That is, git -C <path to work tree> stash

Thanks,
Jake

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

```