git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Quint Guvernator <quintus.public@gmail.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH v3 1/1] general style: replaces memcmp() with starts_with()
Date: Mon, 17 Mar 2014 16:36:59 -0400	[thread overview]
Message-ID: <CALs4jVFFf2cBU920jRcyh1v9KAxkSS+LnycfYo4quuqjNRsp2g@mail.gmail.com> (raw)
In-Reply-To: <532722ED.1010500@alum.mit.edu>

2014-03-17 12:29 GMT-04:00 Michael Haggerty <mhagger@alum.mit.edu>:
> This hunk uses the magic number "11" a couple lines later.  Junio (I
> think rightly) objected [1] to rewrites in these circumstances because
> they make it even less obvious where the constant came from and thereby
> make the complete elimination of the hard-coded constant *more* difficult.
>
> [1] http://article.gmane.org/gmane.comp.version-control.git/244005

Sure, I can understand that. I'll look through the hunks again with
more context in the diff to try to look for more cases where magic
numbers are used more than once. One of the goals of this revision is
to minimize that, see the commit message.

> In any open-source project it is important to optimize for the time of
> the reviewer, because code-review is a relatively tedious task and is
> therefore often the bottleneck for progress.  Therefore I suggest that
> you turn your approach on its head.  Don't "remove the most
> objectionable hunks" but rather *include only the best hunks*--the ones
> that you can stand behind 100%, which you think are an unambiguous
> improvement, and that the reviewer can accept without reservations.
...
> It would be much better for you to submit only a handful of changes (or
> even only one!) that is perfect, rather than throwing a bunch at the
> wall and asking the reviewer to pick between the good and the bad.  As
> you gain experience and learn about the preferences of the Git project,
> you will get a better feel for the boundary between
> acceptable/unacceptable patches, and *then* you will be able to start
> submitting patches closer to the boundary.

I see. For v4, I will be more discerning as to what I include. I will
try to keep the scope of future patches down and err on the side of
caution when I review my own changes before submitting. Thank you for
the *pointers.

I'm going to give v4 a shot. It should be on the mailing list in an hour or so.

Quint

      reply	other threads:[~2014-03-17 20:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-15 16:39 [PATCH v3 0/1] general style: replaces memcmp() with starts_with() Quint Guvernator
2014-03-15 16:39 ` [PATCH v3 1/1] " Quint Guvernator
2014-03-17 16:29   ` Michael Haggerty
2014-03-17 20:36     ` Quint Guvernator [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALs4jVFFf2cBU920jRcyh1v9KAxkSS+LnycfYo4quuqjNRsp2g@mail.gmail.com \
    --to=quintus.public@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=mhagger@alum.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).