Re: What's cooking in git.git (Dec 2015, #05; Tue, 15)

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 15, 2015, 23:36 UTC
Message-ID: <xmqqbn9rffo0.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20151215233207.GA30294@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 19 quoted lines

>> * jc/strbuf-gets (2015-10-28) 17 commits
>> [...]
>> 
>>  Teach codepaths that communicate with users by reading text files
>>  to be more lenient to editors that write CRLF-terminated lines.
>>  Note that this is only about communication with Git, like feeding
>>  list of object names from the standard input instead of from the
>>  command line, and does not involve files in the working tree.
>> 
>>  Waiting for review.
>
> I like the intent here, but I was a little disappointed that we end up
> with two almost identical strbuf functions. But even if the ultimate
> endgame is to drop back to one, the conservative route is to keep them
> both until all new code paths have "opted in" to the new behavior.
> However, I found the naming confusing: it was not at all clear to me
> which of strbuf_gets and strbuf_getline did the CRLF-munging. Perhaps
> it would be more obvious if the new one was strbuf_getline_crlf or
> something. I dunno.

There already was strbuf_getline_crlf(), and I wanted a new name to be conservative. It was modelled after gets() (not fgets()) that removes the trailing line terminator, but there may have been better names. I dunno, either.

Thanks.