From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Danny Lin <danny0838@gmail.com>, git develop <git@vger.kernel.org>
Subject: Re: [PATCH] contrib/subtree: portability fix for string printing
Date: Fri, 08 May 2015 11:44:23 -0700 [thread overview]
Message-ID: <xmqqpp6alxiw.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAPig+cQQSrQiSzp7Jat8LYH+RqYdpJ2XCXweAtrYE_QoLzSznQ@mail.gmail.com> (Eric Sunshine's message of "Fri, 8 May 2015 13:56:34 -0400")
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Fri, May 8, 2015 at 1:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Danny Lin <danny0838@gmail.com> writes:
>>
>>> Replace echo using printf in debug() and say() for
>>> better portability.
>>>
>>> Also re-wrap previous 'say -n "$str<CR>"' using a new
>>> function progress() to prevent CR chars included in the
>>> source code, which could be mal-processed in some shells.
>>> For example, MsysGit trims CR before executing a shell
>>> script file in order to make it work right on Windows
>>> even if it uses CRLF as linefeeds.
>>>
>>> Signed-off-by: Danny Lin <danny0838@gmail.com>
>>> ---
>>
>> Thanks, this looks good. Will apply with a little bit of tweak in
>> the log message.
>
> Hmm, I would say that the changes to debug() and say() should either
> be dropped or moved to a separate patch (along with the first
> paragraph of the commit message). With the introduction of the
> progress() abstraction, there is no longer any need for changes to
> say(), and the "better portability" rationale for changing say() and
> debug() is never properly explained, and is thus nebulous at best.
I justified them in this way.
contrib/subtree: portability fix for string printing
'echo -n' is not portable, but this script used it as a way to give
a string followed by a carriage return for progress messages.
Introduce a new helper shell function "progress" and use printf as a
more portable way to do this. As a side effect, this makes it
unnecessary to have a raw CR in our source, which can be munged in
some shells. For example, MsysGit trims CR before executing a shell
script file in order to make it work right on Windows even if it
uses CRLF as linefeeds.
While at it, replace "echo" using printf in debug() and say() to
avoid tempting people introducing the same bug.
Signed-off-by: Danny Lin <danny0838@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
next prev parent reply other threads:[~2015-05-08 18:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-07 3:39 [PATCH] contrib/subtree: fix linefeeds trimming for cmd_split() Danny Lin
2015-05-07 3:43 ` Danny Lin
2015-05-07 5:10 ` Danny Lin
2015-05-07 18:33 ` Junio C Hamano
2015-05-08 0:51 ` [PATCH] contrib/subtree: portability fix for string printing Danny Lin
2015-05-08 0:56 ` Danny Lin
2015-05-08 17:49 ` Junio C Hamano
2015-05-08 17:56 ` Eric Sunshine
2015-05-08 18:44 ` Junio C Hamano [this message]
2015-05-08 18:55 ` 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=xmqqpp6alxiw.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=danny0838@gmail.com \
--cc=git@vger.kernel.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.