Luciano Rocha <luciano@xxxxxxxxxxx> writes: > Currently, passing the `--bare' option to git-init proper doesn't work, and > gives no indication that `git --bare init' would work instead: > > $ git init --bare > usage: git-init [-q | --quiet] [--template=<template-directory>] [--shared] > > Treat the `--bare' option internally in builtin-init-db. > > Also, fix the usage string, synchronising it with the synopsis in the > documentation. > > Signed-off-by: Luciano Rocha <strange@xxxxxx> It could be argued that this kind of "special casing to help common mistake situation" would in the long run hamper the new users in understanding what --bare means, because one who uses "git init --bare" will not realize that --bare is an option to "git" potty in general and can be given when invoking other git commands. On the other hand, many commands do work sensibly inside a bare repository already, and "init" is truly special in that it cannot inspect the surroundings to guess if the user wants to create a bare repository or one with a work-tree because there isn't a repository yet. In that sense, probably people not learning "git --bare" is not such a loss after all. In general, I am not particularly fond of this kind of special casing, but initializing a bare repository would be a common enough operation that I personally think it is probably Ok to take this as an exception. Opinions? Breakages? -- 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
