Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > I agree that sorting by topic is easier to read. Rarely do you look up > the meaning of an option you know, but you look up an option for a > meaning. If it is "rarely" or not depends on how familiar you are with the tool, and what question you are asking. I recently asked this: "I know there are two options, audio and video encoding bitrates, and vaguely recall they are not named symmetrically. Were they -ab vs -b, or -b vs -vb?". An alphabetical _index_ would have helped in such a situation, but so would typing "/-ab" or "/-b " in less. When you are looking for an option but already know the concepts and you have seen the documentation in the past (e.g. "I know the documentation groups audio options and video options separately"), I'd agree that it is often easier to locate what you are looking for if things are not alphabetical but grouped by what they do and what they act on. Looking at the existing git-tag documentation from that point of view, we present them in not quite nice (but not too random) order. -a (annotated tag creation), -s (annotated signed tag creation), -u (additional data for annotated signed tag creation), -f (additional option for tag creation), -d (delete action) -v (show option) -n (show option) -l (show option) -m (creation option) -F (creation option) I think the ideal order should be something like: -a/-s/-u/-f/-m/-F/-l/-v/-n/-d That is, actions are orderd by create, view, delete, and in each action, options are from primary to fringe. - 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
