Well, the thing is, it's not a special case any more, and you can now see
the code, and say "that's obviously correct".
The whole point of that function is to compare a index entry with the stat
information, and it does that by validating it in special ways. It used to
be that the "ce_mode = 0" was a special case. Now it isn't.
A deleted entry can obviously never match an entry that is still on disk
(regardless of *any* other issues). So now the
if (ce->ce_flags & CE_REMOVE)
return MODE_CHANGED | DATA_CHANGED | TYPE_CHANGED;
statement is in no way a special case - rather the reverse, it's a lot
more obvious than testing for inode ownership changes etc.
So I removed the comment, because it doesn't make sense any more.
Of course, I could have - instead of deleting it - changed it from
"Special case: .." to something like "A deleted index entry doesn't match
any on-disk file", but does that actually add any information to the above
two lines? Sure, we can comment things, but shouldn't we comment the ones
that are subtle or odd, rather than the obvious ones?
This was why the CE_REMOVE bit was done in the first place: to remove the
rather special case of ce_mode being zero meaning something special.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
