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

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

From
Derrick Stolee <stolee@gmail.com>
Date
Apr 18, 2018, 12:50 UTC
Message-ID
<287d6c83-2c7e-3138-def4-fee5d9cb9e48@gmail.com>
In-Reply-To
<xmqqpo2xjpf6.fsf@gitster-ct.c.googlers.com>
On 4/17/2018 9:04 PM, Junio C Hamano wrote:
Show 28 quoted lines
> Stefan Beller <sbeller@google.com> writes:
>
>>>   What's the doneness of this thing?  I didn't recall seeing any
>>>   response, especially ones that demonstrated the reviewer carefully
>>>   read and thought about the issues surrounding the code.  Not that I
>>>   spotted any problems in these patches myself, though.
>> Stolee and Brandon provided a "quick LGTM" type of review
>> https://public-inbox.org/git/20180409232536.GB102627@google.com/
>> https://public-inbox.org/git/9ddfee7e-025a-79c9-8d6b-700c65a14067@gmail.com/
> Yup.  Giving positive reviews is harder than giving constructive
> criticism.  Much harder.
>
> As readers cannot tell from a "quick LGTM" between "I didn't read it
> but it did not smell foul" and "I read it thoroughly, understood how
> the solution works, it was presented well, and agree with the design
> and implementation---there is nothing to add", the reviewers need to
> come up with some way to express that it is the latter case rather
> than the former.
>
> I would not claim that I've perfected my technique to do so, but
> when responding to such a "good" series, I rephrase the main idea in
> the series in my own words to show that I as a reviewer read the
> series well enough to be able to do so, perhaps with comparison with
> possible alternatives I could think of and dicussion to argue that
> the solution presented in the series is better, in an attempt to
> demonstrate that I am qualified to say "this one is good" with good
> enough understanding of both the issue the series addresses and the
> solution in the series.
I'm sorry that my second message was terse. My response to v1 [1] was
 > I looked through these patches and only found one set of whitespace > 
errors. Compiles and tests fine on my machine. > > Reviewed-by: Derrick 
Stolee <dstolee@microsoft.com> So, I pulled the code, went through it 
patch-by-patch, and saw that the transformations were made using the 
established pattern. The second review was to chime in that my v1 
comments had been addressed. Thanks, -Stolee
[1] 
https://public-inbox.org/git/6c319100-df47-3b8d-8661-24e4643ada09@gmail.com/
Previous: Junio C HamanoNext: Junio C Hamano
Message 5 of 18 in “What's cooking in git.git (Apr 2018, #02; Tue, 17)”
  1. Junio C HamanoApr 17, 2018
  2. Eric SunshineApr 17, 2018
  3. Stefan BellerApr 17, 2018
  4. Junio C HamanoApr 18, 2018
  5. Derrick StoleeApr 18, 2018
  6. Junio C HamanoApr 18, 2018
  7. Jonathan TanApr 18, 2018
  8. Junio C HamanoApr 18, 2018
  9. Christian HesseApr 18, 2018
  10. Junio C HamanoApr 18, 2018
  11. Elijah NewrenApr 18, 2018
  12. Junio C HamanoApr 18, 2018
  13. Sergey OrganovApr 19, 2018
  14. js/rebase-recreate-merges, was Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)Johannes Schindelin, Apr 20, 2018
  15. Taylor BlauApr 22, 2018
  16. Junio C HamanoApr 22, 2018
  17. Taylor BlauApr 22, 2018
  18. Junio C HamanoApr 23, 2018

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.