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

Re: [PATCH v3 0/4] Handle PuTTY (plink/tortoiseplink) even in GIT_SSH_COMMAND

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Feb 1, 2017, 22:17 UTC
Message-ID
<alpine.DEB.2.20.1702012311440.3496@virtualbox>
In-Reply-To
<xmqqr33hoetx.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Wed, 1 Feb 2017, Junio C Hamano wrote:
Show 41 quoted lines
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
> > It is quite preposterous to call this an "iteration" of the patch
> > series, because the code is so different now. I say this because I want
> > to caution that this code has not been tested as thoroughly, by far, as
> > the first iteration.
> >
> > The primary purpose of code review is correctness, everything else is
> > either a consequence of it, or a means to make reviewing easier.
> 
> You are utterly wrong here.
> 
> The primary purpose of code review is to spot and correct the
> problems the submitter has missed.  The problems can span from
> stupid bugs that affect correctness to maintainability, to design
> mistakes, to clarity of explanation for both end users and future
> developers.
> 
> Among them, correctness problems are, as long as the problem to be
> solved is specified clearly enough, the easiest to spot by the
> submitter before the patch is sent out.  The submitter is focused on
> solving one problem, and if the updated code does not even work as
> the submitter advertises it would, that can be caught by the
> submitter before the patch is even sent out.  
> 
> Of course, humans are not perfect, and catching correctness problems
> is important, but that is not the only (let alone primary) thing.
> 
> When a submitter has been focusing on solving one problem, it is
> easy to lose the larger picture and to end up adding something that
> may be "correct" (in the sense of "works as advertised by the
> submitter") but does not fit well with the rest of the system, or
> covers some use cases but misses other important and related use
> cases.  If the "does not fit well" surfaces to the end user level,
> that would become a design problem.  If it affects the future
> developers, that would become a maintainability problem.
> 
> Compared to the correctness issue, these are much harder to spot by
> the submitter alone, who focused so intensely to get his code
> "correct".  The review process is of greater value to spot these
> issues.
We will never agree on this.

From my perspective, design, explanation and maintainability are a consequence of making it easy for reviewers to spot where the code is incorrect.

And correctness is not covered by "the submitter tested this". Correctness includes all the corner cases, where the "many eyes make bugs shallow" really shines.

I'd rather have reviewers find bugs than users.

I will *never* be a fan of a review process that pushes correctness to a back seat (yes, it is much harder than spotting typos or lines longer than 80 columns per row, but the ultimate goal is to deliver value to the end user, not to make life easy for the maintainer).

Ciao, Johannes

Previous: Junio C HamanoNext: Junio C Hamano
Message 37 of 38 in “connect: handle putty/plink also in GIT_SSH_COMMAND”
  1. connect: handle putty/plink also in GIT_SSH_COMMANDJohannes Schindelin, Jan 2, 2017
  2. Junio C HamanoJan 8, 2017
  3. Junio C HamanoJan 9, 2017
  4. Johannes SchindelinJan 9, 2017
  5. Junio C HamanoJan 9, 2017
  6. Johannes SchindelinJan 9, 2017
  7. Junio C HamanoJan 9, 2017
  8. Johannes SchindelinJan 25, 2017
  9. Junio C HamanoJan 25, 2017
  10. Junio C HamanoJan 25, 2017
  11. Johannes SchindelinJan 26, 2017
  12. Jeff KingJan 25, 2017
  13. Junio C HamanoJan 25, 2017
  14. Johannes SchindelinJan 26, 2017
  15. 0/3 Handle PuTTY (plink/tortoiseplink) even in GIT_SSH_COMMANDJohannes Schindelin, Jan 26, 2017
  16. 1/3 connect: handle putty/plink also in GIT_SSH_COMMANDJohannes Schindelin, Jan 26, 2017
  17. 2/3 connect: rename tortoiseplink and putty variablesJohannes Schindelin, Jan 26, 2017
  18. 3/3 connect: Add the envvar GIT_SSH_VARIANT and ssh.variant configJohannes Schindelin, Jan 26, 2017
  19. Junio C HamanoJan 26, 2017
  20. Johannes SchindelinJan 27, 2017
  21. Junio C HamanoJan 27, 2017
  22. Johannes SchindelinFeb 1, 2017
  23. Junio C HamanoFeb 1, 2017
  24. 0/4 Handle PuTTY (plink/tortoiseplink) even in GIT_SSH_COMMANDJohannes Schindelin, Feb 1, 2017
  25. 1/4 connect: handle putty/plink also in GIT_SSH_COMMANDJohannes Schindelin, Feb 1, 2017
  26. 2/4 connect: rename tortoiseplink and putty variablesJohannes Schindelin, Feb 1, 2017
  27. 3/4 git_connect(): factor out SSH variant handlingJohannes Schindelin, Feb 1, 2017
  28. 4/4 connect: Add the envvar GIT_SSH_VARIANT and ssh.variant configJohannes Schindelin, Feb 1, 2017
  29. Junio C HamanoFeb 1, 2017
  30. Junio C HamanoFeb 1, 2017
  31. Johannes SchindelinFeb 1, 2017
  32. Junio C HamanoFeb 1, 2017
  33. Johannes SchindelinFeb 1, 2017
  34. Junio C HamanoFeb 1, 2017
  35. Johannes SchindelinFeb 1, 2017
  36. Junio C HamanoFeb 1, 2017
  37. Johannes SchindelinFeb 1, 2017
  38. Junio C HamanoFeb 1, 2017

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.