Re: Comparing the working tree with a commit should be independent of the index

[Maaartin <grajcar@seznam.cz>]

On 08/18/2012 11:19 PM, Junio C Hamano wrote:
>> Instead I get "deleted file". Adding the file to the index changes
>> it. This is IMHO a bug.
>
> Among the 7 interesting cases, a path missing from the index have 3
> interesting cases.
> 
>     In $commit	On filesystem
> 
>     Yes		Yes
>     Yes		No
>     No		Yes
> 
> and your case is the first one.  What do you want to see happen for
> other two cases?  I would guess "deleted" and "added", as anything
> else would not be internally consistent.

Sure.

> "git diff" compares contents in the index and in the working tree.
> "git diff HEAD" compares contents in HEAD and in the working tree.
> 
> The definition of paths in the working tree in these sentences is
> not "all files on the filesystem", or "all files on the filesystem,
> filtered with the ignore mechanism".  It is "all files on the
> filesystem that are in the index", and that is why you see a path
> that is in the commit and on the filesystem but not in the index
> as deleted.

That explains it all.

> This definition worked well for us, because that will give a clean
> semantics to "git diff HEAD": what change would I be recording if I
> said "git commit -a" at this point?

Ok, I see. I nearly always inspect changes to be committed via "git gui", so I don't care much about what "git commit -a" does.

> And that is why "git add" on the path changes the output as you
> observed in your message.  It is an intended behaviour.  If you did
> not tell Git that you want a path that does not exist in the index
> with "git add", the path will not participate in the next commit
> created by "git commit -a", and "git diff HEAD" should not talk
> about it.  If the path is only in the index, not showing it as
> deletion as you saw is actually dangerous.  "git commit -a" will
> record the deletion of the path in the commit, even though you
> checked with the "git diff HEAD" before you commit to make sure you
> didn't change it.

This is a good point. The deletion itself is easily undone, but git wouldn't record the new file content, which could be a problem for me.

> Of course, our definition of the set of working tree files does not
> have to be the only one.  Instead, it could be something that
> changes the semantics of "git diff HEAD" output to: what change
> would I be recording if I said "git add -A && git commit" at this
> point?

This was more or less my POW. Or more exactly, I simply just wanted to compare the state seen in the filesystem against an old commit.

> The updated semantics will be far less useful than the current one,
> but it still is an understandable one.  You could introduce a new
> option (mode of operation to "git diff") to make it include
> untracked but not ignored paths to the set of paths on the working
> tree side of the comparison, but I do not think it is useful.

Such a behavior would suit me, but I can live with the current one. There aren't much cases when it makes a difference and git commands have already a lot of options.

> In short, I do not think there is a bug in the current behaviour.

I can live with it. Many thanks for your answer.

Do you care to copy-paste something to [1], so I could accept your answer? Otherwise, I'll do it, so the information is there.

[1]: http://stackoverflow.com/questions/8452820/how-to-compare-the-working-tree-with-a-commit

Regards, Maaartin.