Maaartin <grajcar@xxxxxxxxx> 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.
--
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