Description
There appears to be a surprising interaction between -M / --must-match-untagged and the normal // tagged/preferred-path behavior.
The documentation says that paths after // are tagged/preferred and that, when duplicates exist in both preferred and unpreferred paths, the preferred file will count as the original. It also describes -m / -M as --must-match-tagged / --must-match-untagged.
However, with rmlint 2.10.3, adding -M causes an untagged/LHS file to be selected as the original, overriding the normal tagged/RHS preference.
For a duplicate group spanning both sides, I observe:
| Command |
Original side |
rmlint lhs // rhs |
RHS / tagged |
rmlint -m lhs // rhs |
RHS / tagged |
rmlint -M lhs // rhs |
LHS / untagged |
rmlint -mM lhs // rhs |
LHS / untagged |
I reproduced this directly with rmlint 2.10.3, including through the JSON formatter: with -mM, an LHS entry receives "is_original": true while the RHS entries are treated as duplicates.
The behavior appears to come from the post-processing original-selection comparator:
} else if((a->is_prefd != b->is_prefd) &&
(cfg->keep_all_untagged || cfg->must_match_untagged)) {
return (a->is_prefd - b->is_prefd);
}Current develop appears to retain this behavior and explicitly notes that the -[kKmM] options take priority.
Why this is limiting
There does not appear to be a clean way to express:
Require a duplicate group to contain both tagged and untagged files, while independently choosing which side should supply the original.
For example, I would like:
to be able to mean:
Require both sides; prefer rhs.
Likewise, reversing the inputs could naturally provide the opposite preference:
Require both sides; prefer the original logical LHS.
Request
Is --must-match-untagged intentionally supposed to affect original selection in addition to determining which duplicate groups qualify?
If not, would it make sense for -m / -M to act only as group-membership constraints, leaving the existing // tagged/preferred-path mechanism to determine original preference?
If the current -M behavior needs to remain for compatibility, could rmlint instead provide a way to control original-side preference independently, conceptually something like:
--prefer-tagged
--prefer-untagged
The exact interface is not important. The main request is to make group-membership requirements and original-selection preference independently controllable.
Description
There appears to be a surprising interaction between
-M/--must-match-untaggedand the normal//tagged/preferred-path behavior.The documentation says that paths after
//are tagged/preferred and that, when duplicates exist in both preferred and unpreferred paths, the preferred file will count as the original. It also describes-m/-Mas--must-match-tagged/--must-match-untagged.However, with rmlint 2.10.3, adding
-Mcauses an untagged/LHS file to be selected as the original, overriding the normal tagged/RHS preference.For a duplicate group spanning both sides, I observe:
rmlint lhs // rhsrmlint -m lhs // rhsrmlint -M lhs // rhsrmlint -mM lhs // rhsI reproduced this directly with rmlint 2.10.3, including through the JSON formatter: with
-mM, an LHS entry receives"is_original": truewhile the RHS entries are treated as duplicates.The behavior appears to come from the post-processing original-selection comparator:
Current
developappears to retain this behavior and explicitly notes that the-[kKmM]options take priority.Why this is limiting
There does not appear to be a clean way to express:
For example, I would like:
to be able to mean:
Likewise, reversing the inputs could naturally provide the opposite preference:
Request
Is
--must-match-untaggedintentionally supposed to affect original selection in addition to determining which duplicate groups qualify?If not, would it make sense for
-m/-Mto act only as group-membership constraints, leaving the existing//tagged/preferred-path mechanism to determine original preference?If the current
-Mbehavior needs to remain for compatibility, could rmlint instead provide a way to control original-side preference independently, conceptually something like:The exact interface is not important. The main request is to make group-membership requirements and original-selection preference independently controllable.