Junio C Hamano <gitster@xxxxxxxxx> writes: >> We had some discussion during review club about this, where the idea of >> using "--porcelain" came up because many commands use that when >> switching into a machine readable format. >> >> In addition, this format not only changes the output but also moves it >> from being on stderr to stdout, which is a hint that the intended usage >> of the command is now a little different. > > A little different from what? I do not think the answer would be > "other program's --porcelain mode", as sending them to stdout would > be one of the things that make the output easier for programs to > parse, so it does sound like very much in the same spirit as "git > status --porcelain" where its output format gets tweaked to be more > machine friendly. > > The output with "--porcelain" option enabled tend to be less human > friendly and the distinction between Porcelain (for humans) and > plumbing (for scripts) is reversed in the use of the word there---it > started as "this is the option for those who write Porcelain > commands to use", but still it is not a very good name for the > option. > > I am perfectly OK if the plan is to uniformly use --output-format > (or something equally more descriptive) and migrate and deprecate > the "--porcelain" option away from existing commands. I agree that --porcelain is a confusing name that would be nice to deprecate, but I don't think --output-format captures all of the intent of "operate in a machine-friendly mode instead of a human-friendly one". Unfortunately, if we had picked --plumbing from the beginning, I doubt we would be having this discussion today :/ E.g. machines (Unix ones at least?) like to have output on stdout and to be able to request NUL-terminated output. It's unfortunate that if we don't piggyback onto --output-format, we run into option precedence problems (like Patrick mentioned), but I'd find it more confusing that --output-format=[porcelain|full|compact] don't behave the same way. I don't think this puts us in a better spot with regards to option precedence either. Consider: git fetch --output-format=full -z <...> The only way to respect both options is to have -z affect the human-readable output, which isn't the end of the world, but it seems unnecessary. Perhaps something like --machine instead?
