Junio C Hamano wrote:

Felipe Contreras [off-list ref] writes:

quoted

quoted

The "author" refers to the author of the "proposed log message" of
the patch in question, i.e. me in this case.  The author of the
patch under discussion thinks it is, so asking "Is it?",

This is the full quote:

====
Let's fix the interactions of these bits to first make "-s" work as intended.
====

If instead you meant this:

====
Let's fix the interactions of these bits to first make "-s" work as I intend.
====

Then that's not a rationale, you are essentially saying "let's do X because I
want".

This will be the last message from me on this.  I wouldn't have even
seen the message I am responding to, as I've already done my "once
every few days sweep the spam folder to find things to salvage",

Comment that breaks the code of conduct:

 * Demonstrating empathy and kindness toward other people
 * Being respectful of differing opinions, viewpoints, and experiences

Is the maintainer exempt from following the code of conduct?

I didn't say and I didn't mean "as I intend", and you know that.

No, I don't know that, because I don't make assumptions.

You said this:

====
  >> Let's fix the interactions of these bits to first make "-s" work as
  >> intended.
  >
  > Is it though?

  Yes.

  If the proposed log message says "as intended", the author thinks it
  is.
====
[1]

Since you are "the author", the above directly translates to "I think it is as
intended", but I responded directly with:

====
  The question is not if the author of the patch thinks this is the way
  `-s` is intended to work, the question is if this is the way `-s` is
  intended to work.
====
[2]

Which is a perfectly valid response, to which you replied:

====
  The "author" refers to the author of the "proposed log message" of
  the patch in question, i.e. me in this case.  The author of the
  patch under discussion thinks it is, so asking "Is it?", implying
  you do not agree, is nothing but a rhetorical question, and doing
  so, without explaining why, wastes time on both sides.
====
[3]

This is not a valid response, because the question was never "does the author
of the patch think this behavior is intended", the question was "is this
behavior intended", and I made that abundantly clear in [2].

So there's only two options:

 a. This is the behavior you intend, and you meant to say this is the
    behaviour you intend.
 b. This is the behavior you think is intended, in which case if you think so
    or not is irrelevant, instead you need to provide a rationale for why
    you think that is the case, which you never did.

If it is `a`: that's not a rationale. If it is `b`: you still need a rationale.
Either way no rationale was provided in the commit message (or anywhere else).

You chose to avoid this question and instead throw personal attacks in [3],
which is not productive.

Fortunately for the project I decided to investigate the whole history behind
the true intention behind `-s` in [4].

In that investigation it became exceedingly clear that the intention behind
`-s` is different from the intention behind `--no-patch`. And it also became
clear that after making `output_format` a bit field: the intention of `-s`
became unclear.

The culmination of that investigation is the thread in which `--no-patch` was
introduced [5]. In that thread Matthieu Moy explained the true purpose was to
make it more accessible to silence the output of `git show`.

Furthermore, Matthieu Moy happened to respond today, and make it even more
clear [6]:

====
  Looking more closely, it's rather clear to me 
  they are not, and that

     git show --raw --patch --no-patch

  should be equivalent to

     git show --raw
====

Which is *exactly* what I and Sergey argued, and to repeat and make it
unquestionably clear:

  `--raw --patch --no-patch` should be equivalent to `--raw`.

Period.

You can throw all the personal attacks you want, but what you think is the
intended behavior of `-s` is irrelevant, the fact is that the intended behavior
of `--no-patch` is independent from the intended behavior of `-s`.

History--and the explicit explanation of the original author--proves that.

So, when I asked "is it though?", that wasn't a rhetorical question intended to
waste time: the answer is clearly: NO.

This is not the way `-s` is intended to work.

quoted

quoted

And it led to unproductive and irritating waste of time number of times, and
eventually you were asked to leave the development community for at least a
few times.

That is blatantly false. As a member of Git's Project Leadership Committee, you
should know precisely how many times the committee has excercised this power,
and it hasn't been "a few times", it has been one time.

You were asked to leave in May 2014, and according to that message
from May 2014 [*1*],

This is the worst kind of misrepresentation.

The fact that *one person* said something, doesn't mean *the community* said that.

Anybody who is the leader of any organization should understand that the
opinion of *one person* is not the same as the opinion of a whole community.

And this is--once again--a smoke screen.

Whatever one person said in 2014 is totally and completely irrelevant to the
topic at hand.

---

The commit message of the patch does not explain why the behavior of `-s`
should be changed in a backwards-incompatible way.

[1] https://lore.kernel.org/git/xmqqsfc62t8y.fsf@gitster.g/ (local)
[2] https://lore.kernel.org/git/6459c31038e81_7c68294ee@chronos.notmuch/ (local)
[3] https://lore.kernel.org/git/xmqqjzxgzua0.fsf@gitster.g/ (local)
[4] https://lore.kernel.org/git/645c5da0981c1_16961a29455@chronos.notmuch/ (local)
[5] https://lore.kernel.org/git/1373893639-13413-1-git-send-email-Matthieu.Moy@imag.fr/ (local)
[6] https://lore.kernel.org/git/4f713a29-1a34-2f71-ee54-c01020be903a@univ-lyon1.fr/ (local)

-- 
Felipe Contreras