Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > Sergey Organov <sorganov@xxxxxxxxx> writes: > > > >> No problem from my side, but are you sure? > > > > Absolutely. > > > > I've seen people just say "we document a failed one" and leave it at > > that, without attempting to fix. I am trying to see if pushing back > > at first would serve as a good way to encourage these known failure > > to be fixed, without accumulating too many expect_failure in our > > test suite, which will waste cycles at CI runs (which do not need to > > be reminded something is known to be broken). I will try not to do > > this when I do not positively know the author of such a patch is > > capable enough to provide a fix, though, and you are unlucky enough > > to have shown your abilities in the past ;-) > > I ended up spending some time digging history and remembered that > "--no-patch" was added as a synonym to "-s" by d09cd15d (diff: allow > --no-patch as synonym for -s, 2013-07-16). These > > git diff -p --stat --no-patch HEAD^ HEAD > git diff -p --raw --no-patch HEAD^ HEAD > > would show no output from the diff machinery, patches, diffstats, > raw object names, etc. > > And this turns out to be a prime example why the approach to ask > contributors do more, would help the project overall. It would also help the project to reward the contributors who actually do more. Otherwise why would a contributor feel incentivized to do more, if that work is simply going to land flat on the ground? > It hopefully would have been "ah, the intent is not documented > correctly, and here is a documentation patch to fix it." That would be assuming that the intent of a developer is all that matters. I disagree. What a reasonable user would expect also matters. > When a command does not behave the way one thinks it should, being > curious is good. Reporting it as a potential bug is also good. But > it would help the project more if it was triaged before reporting it > as a potential bug, if the reporter is capable of doing so. This entirely depends on one's definition of "bug". To me a bug is unexpected behavior. Some people think documenting unexpected behavior makes it not a bug, but to me it's just a documented bug. "It's not a bug, it's a feature!" > Those who encounter behaviour unexpected to them are more numerous > than those who can report it as a potential bug (many people are not > equipped to write a good bug report), Is it just unexpected to them? Or is it unexpected to most users? So what would a reasonable user expect `--no-patch` to do? I think a reasonable user would expect it to negate the effect of `--patch`, and nothing more. The fact that a minority of users expect `--no-patch` to disable all output--not just the one of `--patch`--would not make it not a bug in my book. > Those who can come up with a solution is even more scarse. And those who can come up with a solution that the maintainer deems worthy of merging are way, way scarcer. -- Felipe Contreras
