On Fri, Apr 05, 2019 at 08:42:29PM +0200, SZEDER Gábor wrote: > > > Don't run git commands upstream of a pipe, because the pipe hides > > > their exit code. This applies to several other tests below as well. > > > > I disagree with that rule here. We're not testing "cat-file" in any > > meaningful way, but just getting some stock output from a known-good > > commit. > > It makes auditing harder and sets bad example. I disagree that it's a bad example. Just because a reader might not realize that it is sometimes OK and sometimes not, does not make it bad to do so in the OK case. It means the reader needs to understand the rule in order to correctly apply it. I am sympathetic to the auditing issue, though. I dunno. In this case it is not too bad to do: git cat-file commit $commit >good-commit && perl ... <good-commit >broken-commit but I am not sure I am on board with a blanket rule of "git must never be on the left-hand side of a pipe". > > > Wouldn't a 'sed' one-liner suffice, so we won't have yet another perl > > > dependency? > > > > Heh, this was actually the subject of much discussion before the patches > > hit the list. If you can write such a one-liner that is both readable > > and portable, please share it. I got disgusted with sed and suggested > > this perl. > > Hm, so the trivial s/// with '\n' in the replacement part is not > portable, then? Oh, well. I don't think it is, but I could be wrong. POSIX does say that "\n" matches a newline in the pattern space, but nothing about it on the RHS of a substitution. I have a vague feeling of running into problems in the past, but I could just be misremembering. We also tried matching /^tree/ and using "a\" to append a line, but it was both hard to read and hit portability issues with bsd sed. -Peff
