On 4/26/2023 1:23 PM, Junio C Hamano wrote: > Jacob Keller <jacob.e.keller@xxxxxxxxx> writes: > >>> Yeah, I'd be perfectly happy to rename this to `--format=porcelain`. >>> I'll wait for the Review Club that discusses this patch set tomorrow and >>> will send a new version with that change afterwards if nobody disagrees. >>> >>> Patrick >> >> 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. A little different from using git fetch normally where all output is stderr and is generally "this is what I did" but which was obviously not intended to be parsed by scripts but instead by the human who ran the command. > > 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. Yea the option sort of means "to be used by those implementing porcelain" and its definitely a bit confusing. > > 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. > > Thanks. That makes sense to me as well.
