diff-index --cached on bare repository

Johannes Gilger· Jan 30, 2009, 16:13 UTC · lore

Hi list,

today I stumbled over the output of "git diff-index --cached HEAD" in a bare repository. While diff-index HEAD just reminds me that I got to have a work-tree, --cached outputs all the files in HEAD as deleted. The question is if this is intended behaviour? Or is it irrelevant because diff-index is only plumbing? I found a mail of the gitk-team working around this, which is funny because I discovered this while working on GitX.

So please, enlighten me ;)

Greetings, Jojo

-- 
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81  882C 58EE B178 42F6 DE81

Jeff King· Jan 30, 2009, 20:06 UTC · re: Johannes Gilger · lore

Re: diff-index --cached on bare repository

On Fri, Jan 30, 2009 at 04:13:53PM +0000, Johannes Gilger wrote:

Show 7 quoted lines

> today I stumbled over the output of "git diff-index --cached HEAD" in a 
> bare repository. While diff-index HEAD just reminds me that I got to 
> have a work-tree, --cached outputs all the files in HEAD as deleted. The 
> question is if this is intended behaviour? Or is it irrelevant because 
> diff-index is only plumbing? I found a mail of the gitk-team working 
> around this, which is funny because I discovered this while working on 
> GitX.

Generally commands which don't make sense in a bare repository are forbidden. But diff-index _can_ work in a bare repository, since there is no reason you can't do index-only operations. However, a bare repo has no index by default, in which case diff-index shows the results you saw.

So no, it's not a bug, but it is potentially confusing. I think nobody ever worried about it because diff-index is plumbing, so users are unlikely to stumble into it.

-Peff