git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 3/6] clean: read user input with strbuf_getline()

From
MNMoritz Neeb <lists@moritzneeb.de>
Date
Feb 22, 2016, 07:40 UTC
Message-ID
<56CABB8B.2070502@moritzneeb.de>
In-Reply-To
<CAPig+cSi-4R-a=HVmpCWAZ3kr=yQtJ9GdT-JZ4hJ2kmqg-edVA@mail.gmail.com>
On 02/22/2016 03:27 AM, Eric Sunshine wrote:
Show 13 quoted lines
> On Sun, Feb 21, 2016 at 8:20 PM, Moritz Neeb <lists@moritzneeb.de> wrote:
>> The inputs that are read are all answers that are given by the user
>> when interacting with git on the commandline. As these answers are
>> not supposed to contain a meaningful CR it is safe to
>> replace strbuf_getline_lf() can be replaced by strbuf_getline().
>>
>> Before the user input was trimmed to remove the CR. This would be now
>> redundant. Another effect of the trimming was that some (accidentally)
>> typed spaces were filtered. But here we want to be consistent with similar UIs
>> like interactive adding, which only accepts space-less input.
> 
> I don't at all insist upon it, but this behavior change feels somewhat
> like it ought to be in its own commit.

You're right, two commits would be nicer. I was also thinking about splitting up the three codepaths, but I decided all of the clean-interaction belongs together.

Show 6 quoted lines
> I'm also not convinced that
> making this consistent with the less forgiving behavior of
> "interactive adding" is desirable (rather the reverse: that that case
> should be more flexible). However, I wasn't following the discussion
> with Junio closely, and perhaps missed you two agreeing that this is
> preferable.

To summarize the discussion with Junio: We were not directly talking about that. Two aspects from the whole discussion were that I should decide something and justify a stance (which I did) and that it's also beneficial to think aloud (which I forgot).

In fact, I was surprised, that interactive adding is that strict. I should've added that to the discussion. I am at the moment sometimes unsure whether I find things weird because git standards are different than what I'd expect or because things really should be changed. So I went for the former and decided to go for consistency with the base. I'd expect, from my own behaviour, interactive adding is used by far more than interactive cleaning, which might be an argument to adapt the latter.

But now that we're discussing this, I don't really see a benefit from the user perspective, it's more code cleanup.

Previous: Eric SunshineNext: Junio C Hamano
Message 11 of 14 in “replacing strbuf_getline_lf() by strbuf_getline() on trimmed input”
  1. 0/6 replacing strbuf_getline_lf() by strbuf_getline() on trimmed inputMoritz Neeb, Feb 22, 2016
  2. 1/6 quote: remove leading space in sq_dequote_stepMoritz Neeb, Feb 22, 2016
  3. 2/6 bisect: read bisect paths with strbuf_getline()Moritz Neeb, Feb 22, 2016
  4. 4/6 notes: read copied notes with strbuf_getline()Moritz Neeb, Feb 22, 2016
  5. Eric SunshineFeb 22, 2016
  6. Junio C HamanoFeb 22, 2016
  7. 6/6 wt-status: read rebase todolist with strbuf_getline()Moritz Neeb, Feb 22, 2016
  8. Junio C HamanoFeb 22, 2016
  9. 3/6 clean: read user input with strbuf_getline()Moritz Neeb, Feb 22, 2016
  10. Eric SunshineFeb 22, 2016
  11. Moritz NeebFeb 22, 2016
  12. Junio C HamanoFeb 22, 2016
  13. 5/6 remote: read $GIT_DIR/branches/* with strbuf_getline()Moritz Neeb, Feb 22, 2016
  14. Junio C HamanoFeb 22, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.