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

Re: [PATCH v2 1/4] git-p4: add optional type specifier to gitConfig reader

From
Lars Schneider <larsxschneider@gmail.com>
Date
Sep 4, 2015, 07:49 UTC
Message-ID
<BD5C97C8-DA84-4DC2-8745-893510F1D4ED@gmail.com>
In-Reply-To
<xmqqio7ri40h.fsf@gitster.mtv.corp.google.com>
On 03 Sep 2015, at 23:31, Junio C Hamano <gitster@pobox.com> wrote:
Show 34 quoted lines
> Lars Schneider <larsxschneider@gmail.com> writes:
> 
>> In case I agree with a reviewer. What is the more appropriate action?
>> A response like the one above or a new role that includes the change
>> right away? I don’t want to spam the list with lots of tiny changes…
> 
> Responding to review comment like you did with "will do" is
> perfectly fine.
> 
> When you do think you will (eventually) want to send an updated
> patch, there are things other than "will do" that you can say.  "I
> understand what you said, but I am not sure how exactly to make this
> better.  Perhaps lend me a help?" is good, too.
> 
> An explanation, followed by "ok?", in response to "it is unclear
> what you are doing here" (commenting on code) or to "I cannot
> understand what this is trying to say" (commenting on log message),
> is problematic because your intention becomes ambiguous.
> 
> The reviewers are rarely saying "I do not understand; educate me."
> but "I do not understand, and it is likely many others don't, too.
> Make it more easily understandable." is what they mean.
> 
> An explanation with "ok?" can be taken as a sign that you mistook
> the review comment as "educate me".
> 
> 	What I meant was ....  Do you think commenting the code here
> 	with the above description is good enough?  Or do you think
> 	of a way to restructure the code itself to be more self
> 	evident?
> 
> or something like that may be a way to avoid the ambiguity.
> 
> Thanks.
Thank you for the explanation! :-)
Previous: Junio C HamanoNext: larsxschneider@gmail.com
Message 8 of 17 in “git-p4: add support for large file systems”
  1. git-p4: add support for large file systemslarsxschneider@gmail.com, Sep 3, 2015
  2. 1/4 git-p4: add optional type specifier to gitConfig readerlarsxschneider@gmail.com, Sep 3, 2015
  3. Luke DiamandSep 3, 2015
  4. Lars SchneiderSep 3, 2015
  5. Junio C HamanoSep 3, 2015
  6. Lars SchneiderSep 3, 2015
  7. Junio C HamanoSep 3, 2015
  8. Lars SchneiderSep 4, 2015
  9. 2/4 git-p4: add gitConfigInt readerlarsxschneider@gmail.com, Sep 3, 2015
  10. Luke DiamandSep 3, 2015
  11. Lars SchneiderSep 3, 2015
  12. Luke DiamandSep 3, 2015
  13. 3/4 git-p4: return an empty list if a list config has no valueslarsxschneider@gmail.com, Sep 3, 2015
  14. 4/4 git-p4: add support for large file systemslarsxschneider@gmail.com, Sep 3, 2015
  15. Luke DiamandSep 3, 2015
  16. Lars SchneiderSep 3, 2015
  17. Jeff KingSep 4, 2015

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.