Add offsets to bit flag comparisons for GTIndexEntryStatus #547
Conversation
…he values are offset when provided as GTIndexEntry.flags
|
Huh, that's a good catch! Would you be able to write a test that exercises that? |
|
That would be a trick, actually; I haven't been able to find any scenario in which the flags_extended field actually has any data in it, and I hesitate to write a test that assumes the check will fail (particularly since this method doesn't return a failure code, but improperly reports an existing flag by default). If you know of a scenario where these are set, I'd be happy to help with a test, but so far as I can tell there's little reason to expose these methods in Objective-Git at all (the flags field only ever seems to have the NAMEMASK set, which I can't imagine is terribly useful for most applications anyway, and the staged flag never appears to be set, either; it's entirely possible that I'm just missing the applicability of them, of course, since my usage of Objective-Git has been fairly narrow so far). |
|
Fair enough! |
Add offsets to bit flag comparisons for GTIndexEntryStatus
Are you sick of random minor pull requests from me yet? :-)
You'll note on line 81 of the same file that the flags_extended bit flag from libgit2 is shifted 16 bits left in order to combine it with the basic flags field into a single int. However, the comparisons were not shifted, and thus were improperly reporting statuses depending on the bits set in the NAMEMASK portion of the basic flags. This commit fixes the bug.
Incidentally, I have not come across any instances where the flags_extended are actually set (and it appears that they are not intended for external use, anyway). It might be worth considering deprecating this method to avoid confusion for future newbies to Objective-Git.