Re: Comparing the working tree with a commit should be independent of the index
On 08/18/2012 11:19 PM, Junio C Hamano wrote:
Show 15 quoted lines
>> 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.
Show 9 quoted lines
> "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?
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.
Show 10 quoted lines
> 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.
Show 5 quoted lines
> 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.
Show 5 quoted lines
> 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.