Git-MQ

Fork

Reply to this ticket

Having acquired a new laptop, on which I've installed the Manjaro derivative of Arch Linux, initially with git-2.21.0 installed, (and subsequently upgraded to git-2.24.1), I am no longer able to run any Git-MQ command from the v1.0-rc-1 package set; all fail due to reuse of the same short option alias for each of the explicitly specified abbreviations for the --color option, (itself intended as a US spelling alias for the correct World English spelling of --colour). Additionally, those commands which explicitly document availability of the --verbose option fail, because the option is defined twice, (the second definition being the hidden variant which is shared by all Git-MQ commands); this again manifests as a short option reuse bug.

These issues are corrected by commit #078d06b1; the corrections have been incorporated into the git-mq-1.0-rc-2 release.

Reply to this ticket

Having acquired a new laptop, on which I've installed the Manjaro derivative of Arch Linux, initially with git-2.21.0 installed, (and subsequently upgraded to git-2.24.1), I am no longer able to run any Git-MQ command from the v1.0-rc-1 package set; all fail due to reuse of the same short option alias for each of the explicitly specified abbreviations for the --color option, (itself intended as a US spelling alias for the correct World English spelling of --colour). Additionally, those commands which explicitly document availability of the --verbose option fail, because the option is defined twice, (the second definition being the hidden variant which is shared by all Git-MQ commands); this again manifests as a short option reuse bug.

I initially developed Git-MQ on an old LMDE box, on which the installed version of git was git-1.8.5.1; this version did not fail, nor even complain, due to reused/redefined options. In this particular case, the reuse may be justifiable, since each use refers to an explicitly defined alias/abbreviation for identically the same optional feature; however, although justifiable, it isn't necessary. Indeed, in the case of --color abbreviations, no short form alias is required, other than to discriminate short and long forms to make --c an acceptable abbreviation for both --color and --colour; to support this, it is necessary to associate the short form alias with the definition of only --c as a long form option, (since the definitions of all longer abbreviated forms will be unambiguously identified as long form). I will make the necessary adjustment, to accommodate the more pernickety behaviour of more recent git versions.

The case of --verbose redefinition is slightly more difficult to accommodate; it requires some additional logic, to suppress the definition of the hidden variant, when an explicitly visible definition is already in place. I will also add logic, to handle this case.