Jeff King <peff@xxxxxxxx> writes: >> Sorry, Torsten, this is not my doing. So I cannot explain why it is not an >> enum. >> >> I *guess* the rationale for 'c' being the cmdmode of --textconv is "c for >> convert". That is why I chose "w as in worktree" as new cmdmode. > > I think it started as a 'char' because it was representing the > single-letter options of "cat-file -e", "cat-file -s", etc. And then the > textconv patches started the monstrosity of "c". I think it was merely 't' was taken for "-t" (one beauty of using the OPT_CMDMODE for options with shorthand is that we do not need any enum, as the short-form options already form an enum), so "textConv" was the compromise. It could have been 'T' or even \C-t ;-) > I don't think cleaning it up needs to be part of your series, but it > might be nice low-hanging fruit for somebody to clean up on top. I agree. I briefly wondered if we want to add a check to ensure uniqueness of these cmdmode letters in parse_options_check(), but that would forbid us from having synonymous options (e.g. "am --continue" and "am --resolved" both map to the same), so it would not work. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html