Jakub Narebski <jnareb@xxxxxxxxx> writes: > Well, I think it doesn't have to be true: there can be some options > like e.g. '-n' / '--dry-run' that are common to all subcommands, and > in my opinion they could come before subcommand name. That is just a crazy talk. If you have three subcommands a, b and c, and only a and b shares -n, c must learn to reject the option that does not apply. If you have more subcommands and you need to add an option to one of them, you are forcing logic to reject that new option to all other subcommands. That is not a proper way to share option specification. Different subcommands support different options, and if you want to share some options among them, you add a new facility to _allow_ them to share _some_ options, while still allowing them to keep their own option specification table. Otherwise the resulting mess will be unmaintainable. -- 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