> I also wonder who it helps to use <LF> as a field separator. Do you mean the <LF> between the field and the value? If so, it was the format suggested by Phillip [1]. I accepted the suggestion because: 1. It's easy to be parsed 2. It's easy to write (then I could drop the json_write stuff) 3. It's already used by an existing command (git-config) > Once we require consumers to properly handle <NUL>, it does not make > it easier to write such a consumer script if the format uses <LF> > there, does it? Not much... Since the keys contain only letters and dots, any other character would work here, but I wanted to be consistent with something that already exists. However, to the best of my knowledge, we have several null-terminated commands (git ls-files -z, git status -z, git ls-tree -z, etc), but few commands that use LF as a key-value separator (I only remember git config -z). > Besides, wouldn't it possible that field may have to contain any > end-user specified key, including <LF>? In `repo info`, no. This way, it's safe to parse everything before the first <LF> as the key and everything between <LF> and <NUL> as the value. The value may contain a <LF>, however, the first <LF> would still be the separator. Thanks! [1] https://lore.kernel.org/git/223c7cbd-610e-49e2-90e2-5914cbc0f1d7@xxxxxxxxx/
