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

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

[Maaartin]

I've already posted it to SO [1], but got no satisfactory answer. The command

git diff mycommit

compares the working tree against mycommit, so it should not depend on the index. But it does as this example shows:

git init
echo A > A.txt; git add .; git commit -m A; git branch A
echo B > B.txt; git add .; git commit -m B; git branch B
git reset --hard A
echo BB > B.txt
git diff B

File B.txt exists both in the working tree and in the commit B, so a proper diff should be shown.

Instead I get "deleted file". Adding the file to the index changes it. This is IMHO a bug.

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

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

[Junio C Hamano]

Maaartin <grajcar@seznam.cz> writes:

> Instead I get "deleted file". Adding the file to the index changes
> it. This is IMHO a bug.

There are 7 interesting combinations for the state of a path.  It
either exists in or missing from the commit you are gving to "git
diff", it either exists in or missing from the index, and it either
exists in or missing from the working tree.  Missing from all is
totally uninteresting, so it leaves 7 combinations.

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.

"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.

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?

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.

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?

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.

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

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

[Maaartin]

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.

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

[Junio C Hamano]

Maaartin <grajcar@seznam.cz> writes:

> On 08/18/2012 11:19 PM, Junio C Hamano wrote:
> ...
>> 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?

I never post to that site, and it has been a long time since I even
visited there (I got an impression that nonnegliglble percentage of
accepted answers were mere crap, and I stopped visiting).

If you think it would help others, just go ahead and give them a
copy and paste with credits.  Everything I write here is Open
Source, so no need to ask for permission.

It may help them in the longer term to include

  http://thread.gmane.org/gmane.comp.version-control.git/203689/focus=203702

to point them to where things happen and where people who matter
hang around.