There should be separate log actions for moves suppressing redirects. Moves saying "without leaving a redirect" should be separated from those with no modifier, while those saying "over a redirect without leaving a redirect" should be separated from those saying "over redirect". The log actions should be "move_suppress_redir" and "move_redir_suppress_redir", or something similar. See also T27799, which is a similar situation for patrol log entries.
|Open||None||T120764 Improve Special:Log|
|Open||None||T109262 Allow users to filter log entries by type (tracking)|
|Open||None||T109264 Allow to filter the move log by types|
|Open||matej_suchanek||T152346 Separate log action for moves suppressing redirects|
Do you mean be able to winnow page moves in Special:Log/move using the new dropdown that allows you to filter actions? Page moves overwritting redirects can be already fetched from Special:Log/move, so just moves with no redirect creation remains if I understand your request correctly. Regards.
I don't think this is a good idea, as it is really confusing if you're querying past log entries. Furthermore, the mix of to booleans into four distinct options doesn't seem really elegant to me.
@MGChecker Well, the same problem would also occur with patrol log entries as well. If you think that this isn't a good idea, then probably T27799 shouldn't have been a good idea either, then. But that was already fixed for newer log entries. Too late to worry about that, sorry. A task similar to T136493 will have to be created for fixing older move log entries.
While this case may be similar, there are some differences to the decision regarding the autopatrol log action. First, the tagging technology wasn't in reach at this time, furthermore there was only one general log_action before. This time, you already hace a table with distinct log_actions, which makes this one much more confusing for users. While fixing entries into the past may be possible, it isn't easy, and the solution you present here isn't really elegant in my opinion, as it's effectively mixing two bit flags into one. If we start to use log_actions that way, soon some may get the idea to merge three or four bit flags into log_action, which can't be wanted.