Brad King <brad.king@xxxxxxxxxxx> writes: > +With `--stdin`, update-ref reads instructions from standard input and > +performs all modifications together. Empty lines are ignored. > +Each non-empty line is parsed as whitespace-separated arguments. "whitespace-separated" implies that we may allow fields separated with not a single SP, but with double SPs or even HTs between them. I personally do not think we should be so loose; it is not like we are allowing the user to type these from the terminal, so limiting "separated by a single SP" may be perfectly adequate, and make it less error prone (e.g. there will not be a confusion "Is 'A SP SP B' A followed by B, or A followed by an empty string followed by B?"). > +Quote arguments containing whitespace as if in C source code. Probably "as if they were strings in C source code". > +Specify updates with lines of the form: > + > + [--no-deref] [--] <ref> <newvalue> [<oldvalue>] > + > +Lines of any other format or a repeated <ref> produce an error. > +Specify a zero <newvalue> to delete a ref and/or a zero <oldvalue> > +to make sure that a ref not exist. Use either 40 "0" or the > +empty string (written as "") to specify a zero value. Use `-z` > +to specify input with no whitespace, quoting, or escaping, and > +terminate each argument by NUL and each line by LF NUL. This is a somewhat interesting choice of the record terminator. Do we have a precedent to use LF NUL elsewhere? If this is the first such case where we need to express variable number of NUL-separated fields in a record, I think I am fine with LF NUL (but I am sure other people would give us a better convention if we ask them politely ;-)), but I just want to make sure we do it the same way as other codepaths, if exist, that have to handle this kind of thing. -- 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