GIT_WORK_TREE not set as expected when changing git repository from a script using a git alias

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

GIT_WORK_TREE not set as expected when changing git repository from a script using a git alias

From: Gabriel Ganne <hidden>
Date: 2016-06-15 23:07:22

Hi,

Following commit d95138e695d99d32dcad528a2a7974f434c51e79 (since
v2.5.1) the following workflow I use seems broken :

I wrote a script to list all git repositories that can be found from
where I am, and then call for each repository a given command.

Given the following tree, where "a" & "b" are git repositories,
├── a
│   ├── a_file
│   └── b
│       └── b_file

If I call the script from a git alias, the content of "a" will be
listed as untracked files from "b".
This is true only when called using the alias.

For example :
$ git all status # called from repository a
 [a]
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        b/

nothing added to commit but untracked files present (use "git add" to track)
 [b]
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    ../b_file

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        ../a_file
        ./

no changes added to commit (use "git add" and/or "git commit -a"

I am afraid I did not understand the commit
d95138e695d99d32dcad528a2a7974f434c51e79, and do not know how to fix
this.
I am working around the issue by setting GIT_WORK_TREE manually.

I attached a sample with my example, the script, and the alias I used.

Best regards,

--
Gabriel Ganne

Re: GIT_WORK_TREE not set as expected when changing git repository from a script using a git alias

From: Duy Nguyen <hidden>
Date: 2016-06-15 23:07:22

On Fri, Dec 4, 2015 at 10:54 AM, Gabriel Ganne [off-list ref] wrote:
Hi,

Following commit d95138e695d99d32dcad528a2a7974f434c51e79 (since
v2.5.1) the following workflow I use seems broken :
You are not the first one bitten [1] by that commit. A fix is being
worked on [2]. Sorry for the trouble.

[1] http://thread.gmane.org/gmane.comp.version-control.git/281608
[2] http://article.gmane.org/gmane.comp.version-control.git/281960
-- 
Duy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help