From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2] diff: fix interaction between the "-s" option and other options
Date: Fri, 12 May 2023 23:32:35 -0600 [thread overview]
Message-ID: <645f20f332476_21e719294d8@chronos.notmuch> (raw)
In-Reply-To: <xmqqpm77zlec.fsf@gitster.g>
Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >> 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.
> >> 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/
[2] https://lore.kernel.org/git/6459c31038e81_7c68294ee@chronos.notmuch/
[3] https://lore.kernel.org/git/xmqqjzxgzua0.fsf@gitster.g/
[4] https://lore.kernel.org/git/645c5da0981c1_16961a29455@chronos.notmuch/
[5] https://lore.kernel.org/git/1373893639-13413-1-git-send-email-Matthieu.Moy@imag.fr/
[6] https://lore.kernel.org/git/4f713a29-1a34-2f71-ee54-c01020be903a@univ-lyon1.fr/
--
Felipe Contreras
next prev parent reply other threads:[~2023-05-13 5:40 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-03 13:41 [PATCH] t4013: add expected failure for "log --patch --no-patch" Sergey Organov
2023-05-03 16:57 ` Junio C Hamano
2023-05-03 17:31 ` Sergey Organov
2023-05-03 18:07 ` Junio C Hamano
2023-05-03 18:32 ` Felipe Contreras
2023-05-03 19:49 ` Sergey Organov
2023-05-04 15:50 ` Junio C Hamano
2023-05-04 18:24 ` Sergey Organov
2023-05-04 20:53 ` Junio C Hamano
2023-05-04 21:37 ` Re* " Junio C Hamano
2023-05-04 23:10 ` [PATCH] diff: fix behaviour of the "-s" option Junio C Hamano
2023-05-05 5:28 ` Junio C Hamano
2023-05-05 16:51 ` Junio C Hamano
2023-05-09 1:16 ` Felipe Contreras
2023-05-05 8:32 ` Sergey Organov
2023-05-05 16:31 ` Junio C Hamano
2023-05-05 17:07 ` Sergey Organov
2023-05-05 16:59 ` [PATCH v2] diff: fix interaction between the "-s" option and other options Junio C Hamano
2023-05-05 17:41 ` Eric Sunshine
2023-05-05 19:01 ` Junio C Hamano
2023-05-05 21:19 ` [PATCH 0/2] dirstat: leakfix Junio C Hamano
2023-05-05 21:19 ` [PATCH 1/2] diff: refactor common tail part of dirstat computation Junio C Hamano
2023-05-05 21:19 ` [PATCH 2/2] diff: plug leaks in dirstat Junio C Hamano
2023-05-09 0:38 ` [PATCH v2] diff: fix interaction between the "-s" option and other options Felipe Contreras
2023-05-09 1:22 ` Junio C Hamano
2023-05-09 3:50 ` Felipe Contreras
2023-05-10 4:26 ` Junio C Hamano
2023-05-10 23:16 ` Felipe Contreras
2023-05-10 23:41 ` Felipe Contreras
2023-05-11 1:25 ` Jeff King
2023-05-13 3:07 ` Felipe Contreras
2023-05-11 1:50 ` Junio C Hamano
2023-05-13 5:32 ` Felipe Contreras [this message]
2023-05-09 1:34 ` [PATCH] t4013: add expected failure for "log --patch --no-patch" Felipe Contreras
2023-05-10 13:54 ` Sergey Organov
2023-05-10 21:54 ` Felipe Contreras
2023-05-09 1:03 ` Felipe Contreras
2023-05-04 18:07 ` Junio C Hamano
2023-05-04 18:26 ` Sergey Organov
2023-05-09 1:07 ` Felipe Contreras
2023-05-10 13:40 ` Sergey Organov
2023-05-10 21:39 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=645f20f332476_21e719294d8@chronos.notmuch \
--to=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).