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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html