[BUG] GIT_INDEX environment variable ignored?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I was trying to use multiple indexes earlier, and ran into an issue which I've summarised into a test case:

$ git init
$ touch file1 && git add file1 && git commit -m "file1"
$ git branch release 
$ touch file2 && git add file2 && git commit -m "file2"
$ cp .git/index .git/indexMaster
$ git checkout release
$ touch file3 && git add file3 && git commit -m "file3"

I then ran ls-files with the --stage option to look at what the index contains.
As expected file1 and file3 are present, we're on the 'release' branch still.

$ git ls-files --stage
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       file1
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       file3

However when I run the same command again, this time using the 
GIT_INDEX env variable to provide the index I previously saved on master,
I don't see file2 like I'd expect...

$ GIT_INDEX=.git/indexMaster git ls-files --stage
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       file1
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       file3

Is this something going wrong, or am I misunderstanding the role of the index/GIT_INDEX variable?

Replicated on 2.5.0.windows.1 and 2.6.1 (Linux).

Thanks,
Ben
��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]