On Thu, Mar 19, 2020 at 03:58:51PM -0700, Junio C Hamano wrote: > >> Workaround this problem by assuming `diff(1)` output is unified > >> if we couldn't make anything from normal-diff format. > > I do not mind working it around, but I am a bit disturbed by an > uneven attitude towards POSIX noncompliance this series has. If > we were willing to break other people's "sed" that does not do BRE > correctly, instead of using '[+]' trick to accomodate them while > making sure that an implementation that does not use nonstandard > extension and does only BRE, we should just similarly be writing > such an implementation of noncompliant diff off as broken, yet we > bend backwards over to make sure we can work with them here. > > IOW, I do not have trouble changing the test so that it works with > noncompliant "diff". But then in the same series, I would prefer to > see the existing test keeps working with a possibly noncompliant > "sed" implementation that has been working well with the tests. I don't think it's inconsistent. Real-world experience trumps standards. We _know_ that there is a real-world diff that generates only unified diffs, and it is not too hard to work around it. So we should do so. A sed that uses ERE and requires backslash-escaping pluses is theoretical at this point. POSIX forbids it, and I would guess that working around it would be more than just the "[+]" we found, because other patterns probably need it, too. But we won't know until we find one to test on. So I'm not entirely against "[+]" as a defensive measure. But I have a slight preference to avoid it until we know it's needed, not because it's hard to do once, but because I don't want to grow too many defensive superstitions if we don't know they're warranted. -Peff
