On Tue, 05 Dec 2006 20:53:30 -0800, Carl Worth wrote: > On Tue, 05 Dec 2006 17:13:20 -0800, Junio C Hamano wrote: > 2. Avoiding a change of semantics triggered by merely applying > pathname arguments without any command-line option or > alternate command name. By the way, the original command-line convention I used in the proposal was that the omission of an optional argument should be equivalent to supplying some default argument. Here's another convention that is also useful to examine: Adding path-name arguments limits the behavior of the command, (and does not otherwise change the semantics). I don't know that this is as universal a convention outside of git, but it's quite strong within git. The path name limiting exists in deep parts of the machinery and allows for things like: git log -- paths... # path-limited version of "git log" git diff -- paths... # path-limited version of "git diff" etc. It's interesting to look at how the various commit commands fit (or do not fit) this convention: git commit paths... git commit --only paths... This command cannot be explained in terms of the semantics of "git commit" (without command-line options). This command _can_ be explained as a path-limited version of "git commit -a". git commit --include paths... This command does something _extra_ to the given paths before executing the equivalent of "git commit". I think this is a fairly unique violation of the path-limiting convention. The proposal I made with commit-working-tree-content and commit-index-content consistently follow the path-limiting convention. I think consistency of command-line conventions like this are important for making the tool usable. And there have been notable improvements to consistency of convention in git recently, (for example, using <since>..[<until>] in git-format-patch rather than <his> <mine>). -Carl
Attachment:
pgpAT2npwroX0.pgp
Description: PGP signature