Re: [PATCH] t4013: add expected failure for "log --patch --no-patch"

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 9, 2023, 01:03 UTC
Message-ID: <64599bdee22b4_7c6829422@chronos.notmuch>
In-Reply-To: <xmqqttwskse5.fsf@gitster.g>

Junio C Hamano wrote:

Show 29 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> > Sergey Organov <sorganov@gmail.com> 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