This changes the return type of GETBIT and is thus breaking. Is it really necessary?
It's probably easier to use GETRANGE and pick out the right bits yourself

When we want fetch multiple bits, this feature would be useful for users.
GETRANGE returns the substring, not bits. So all users need to implement the picking out logic by themselves, or need to use GETBIT at many times.

This changes the return type of GETBIT and is thus breaking.

it's better to add new command like GETBITS separatly?

+1 for the feature though not reviewed the PR yet.

The use case in the real world maybe like this: Suppose item ids {123, 3213, 25231, 723154} are liked by user id 1024. Given a list of item ids [123, 22451, 25231, 53264] and I want to know: Which of them are liked by the user?

Without the feature, I have to call GETBIT for 4 times or use Lua script to make it in just one call.

GETBIT user:1024 123
GETBIT user:1024 22451
GETBIT user:1024 25231
GETBIT user:1024 53264

I can also use SISMEMBER in this case. As you can see in http://redis.io/commands/sismember (also see https://github.com/antirez/redis/issues/846 ) ::

Xujinzheng • 4 years ago
I think is necessary to add command like this :

sismember key member member member ...

Thanks

9 guys +1'ed for this!

BTW, a spare bitmap(https://github.com/antirez/redis/issues/271) would be preferred in the use case I just mentioned, but the data struct behind getbit is bitmap. ;(

I'm not sure that is a good use-case example; in the real world, a "list of
item ids" (for checking which are liked): is unlikely to be contiguous,
except by coincidence. There probably are cases where it fits, I'm not
arguing that. But in that scenario, it would seem that a varadic GETBIT is
more desirable, as in:

GETBIT {key} 1 2 47 192 290

@mgravell is unlikely to be contiguous Definitely! That's quite a bad example and I've updated my reply. Thanks for your advice.

Another use case is for bloom filters: https://github.com/erikdubbelboer/redis-lua-scaling-bloom-filter
For a bloom filter we need to GET and SET multiple bits. Being able to do this in one command will make it slightly faster I guess.

Thank for showing use cases.
It would be better that we pass multiple location of bit to GETBIT as @mgravell mentioned.
I will change it so.

I've changed its design to adding MGETBIT command, in order to keep the return type GETBIT command.

MGETBIT command gets multiple bits like,

127.0.0.1:6379> setbit hoge 1 1
(integer) 1
127.0.0.1:6379> setbit hoge 2 1
(integer) 1
127.0.0.1:6379> setbit hoge 3 1
(integer) 1
127.0.0.1:6379> getbit hoge 1
(integer) 1
127.0.0.1:6379> mgetbit hoge 1 2 3 4
1) (integer) 1
2) (integer) 1
3) (integer) 1
4) (integer) 0

Please take a look.

Hello, by using the new BITFIELD command it is possible to retrieve multiple bitfields (including single bits) in with one call, so this should fix your issue basically. BITFIELD is just a much more powerful way to set and get bits or groups of bits.