All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>, simon@ruderich.org
Cc: Git List <git@vger.kernel.org>, Mahmoud Al-Qudsi <mqudsi@neosmart.net>
Subject: Re: [PATCH] Makefile: make NO_ICONV really mean "no iconv"
Date: Sun, 17 Jun 2018 23:02:45 +0530	[thread overview]
Message-ID: <a079d636-e70d-f383-ae87-ab890a636441@gmail.com> (raw)
In-Reply-To: <CAPig+cQL8rTg+GASp2tSng7PPPYkfeeV2SNyi0D+6-Ep7JKaGg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2296 bytes --]

On Friday 15 June 2018 01:13 PM, Eric Sunshine wrote:
> On Fri, Jun 15, 2018 at 2:58 AM Simon Ruderich <simon@ruderich.org> wrote:
>> On Thu, Jun 14, 2018 at 10:25:03PM -0400, Eric Sunshine wrote:
>>> This patch is extra noisy due to the indentation change. Viewing it with
>>> "git diff -w" helps. An alternative to re-indenting would have been to
>>> "undefine NEEDS_LIBICONV", however, 'undefine' was added to GNU make in
>>> 3.82 but MacOS is stuck on 3.81 (from 2006) so 'undefine' was avoided.
>>
>> Should we put the part about MacOS's make into the commit
>> message? Seems like relevant information for future readers.
> 
> No. The bit of commentary mentioning MacOS's very old 'make' was just
> talking about a possible alternate way of implementing the change.
> That alternative was not chosen, so talking about old 'make' in the
> commit message would be confusing for readers.

Interesting. Documentation/SubmittinPatches reads:

    The body should provide a meaningful commit message, which:
    ...
    <snip>
    ...
    . alternate solutions considered but discarded, if any.

The consensus has changed, maybe? In which case, should we remove that
statement from there?


-- 
Sivaraam

QUOTE:

“The three principal virtues of a programmer are Laziness, Impatience,
and Hubris.”

	- Camel book

Sivaraam?

You possibly might have noticed that my signature recently changed from
'Kaartic' to 'Sivaraam' both of which are parts of my name. I find the
new signature to be better for several reasons one of which is that the
former signature has a lot of ambiguities in the place I live as it is a
common name (NOTE: it's not a common spelling, just a common name). So,
I switched signatures before it's too late.

That said, I won't mind you calling me 'Kaartic' if you like it [of
course ;-)]. You can always call me using either of the names.


KIND NOTE TO THE NATIVE ENGLISH SPEAKER:

As I'm not a native English speaker myself, there might be mistaeks in
my usage of English. I apologise for any mistakes that I make.

It would be "helpful" if you take the time to point out the mistakes.

It would be "super helpful" if you could provide suggestions about how
to correct those mistakes.

Thanks in advance!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-06-17 17:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-14 22:47 Is NO_ICONV misnamed or is it broken? Mahmoud Al-Qudsi
2018-06-15  2:25 ` [PATCH] Makefile: make NO_ICONV really mean "no iconv" Eric Sunshine
2018-06-15  4:20   ` Jeff King
2018-06-15  6:30     ` Eric Sunshine
2018-06-15  6:39       ` Jeff King
2018-06-15  6:58   ` Simon Ruderich
2018-06-15  7:43     ` Eric Sunshine
2018-06-17 17:32       ` Kaartic Sivaraam [this message]
2018-06-17 18:00         ` Eric Sunshine
2018-06-17 18:25           ` Doc/SubmittingPatches: re-phrashing a sentence about alternate solutions (was Re: [PATCH] Makefile: make NO_ICONV really mean "no iconv") Kaartic Sivaraam
2018-06-18  4:20             ` Jeff King
2018-06-18 16:09           ` [PATCH] Makefile: make NO_ICONV really mean "no iconv" Junio C Hamano
2018-06-15  8:15   ` Mahmoud Al-Qudsi
2018-06-17  2:57 ` Is NO_ICONV misnamed or is it broken? Christian Couder
2018-06-17  3:41   ` Eric Sunshine

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=a079d636-e70d-f383-ae87-ab890a636441@gmail.com \
    --to=kaartic.sivaraam@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=mqudsi@neosmart.net \
    --cc=simon@ruderich.org \
    --cc=sunshine@sunshineco.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.