git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Paul Tan <pyokagan@gmail.com>,
	git@vger.kernel.org, Stefan Beller <sbeller@google.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH/WIP 6/8] am: extract patch, message and authorship with git-mailinfo
Date: Wed, 27 May 2015 18:13:56 -0400	[thread overview]
Message-ID: <20150527221356.GE23259@peff.net> (raw)
In-Reply-To: <xmqqtwuxkaxh.fsf@gitster.dls.corp.google.com>

On Wed, May 27, 2015 at 01:44:26PM -0700, Junio C Hamano wrote:

> Paul Tan <pyokagan@gmail.com> writes:
> 
> > @@ -17,6 +34,10 @@ struct am_state {
> >  	struct strbuf dir;            /* state directory path */
> >  	int cur;                      /* current patch number */
> >  	int last;                     /* last patch number */
> > +	struct strbuf msg;            /* commit message */
> > +	struct strbuf author_name;    /* commit author's name */
> > +	struct strbuf author_email;   /* commit author's email */
> > +	struct strbuf author_date;    /* commit author's date */
> >  	int prec;                     /* number of digits in patch filename */
> >  };
> 
> I always get suspicious when structure fields are overly commented,
> wondering if it is a sign of naming fields poorly.  All of the above
> fields look quite self-explanatory and I am not sure if it is worth
> having these comments, spending efforts to type SP many times to
> align them and all.

Just my 2 cents, but I think that grouping and overhead comments can
often make things more obvious. For example:

  struct am_state {
	/* state directory path */
	struct strbuf dir;

	/*
	 * current and last patch numbers; are these 1-indexed
	 * or 0-indexed?
	 */
	int cur;
	int last;

	struct strbuf author_name;
	struct strbuf author_email;
	struct strbuf author_date;
	struct strbuf msg;

	/* number of digits in patch filename */
	int prec;
  }

Note that by grouping "cur" and "last", we can discuss them as a group,
and the overhead comment gives us room to mention their shared
properties (my indexing question is a real question, btw, whose answer I
think would be useful to mention in a comment).

Likewise, by grouping the "msg" strbuf with the author information, it
becomes much more clear that they are all about the commit metadata
(though I would not be opposed to a comment above the whole block,
either).

-Peff

  reply	other threads:[~2015-05-27 22:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-27 13:33 [PATCH/WIP 0/8] Make git-am a builtin Paul Tan
2015-05-27 13:33 ` [PATCH/WIP 1/8] wrapper: implement xopen() Paul Tan
2015-05-27 17:52   ` Stefan Beller
2015-05-27 19:03   ` Torsten Bögershausen
2015-05-27 21:53     ` Jeff King
2015-06-03  8:16       ` Paul Tan
2015-06-04 12:05     ` Paul Tan
2015-05-27 13:33 ` [PATCH/WIP 2/8] wrapper: implement xfopen() Paul Tan
2015-05-27 21:55   ` Jeff King
2015-05-27 13:33 ` [PATCH/WIP 3/8] am: implement patch queue mechanism Paul Tan
2015-05-27 20:38   ` Junio C Hamano
2015-05-27 13:33 ` [PATCH/WIP 4/8] am: split out mbox/maildir patches with git-mailsplit Paul Tan
2015-05-28 23:05   ` Eric Sunshine
2015-06-02 14:27     ` Paul Tan
2015-05-27 13:33 ` [PATCH/WIP 5/8] am: detect mbox patches Paul Tan
2015-05-31 17:16   ` Eric Sunshine
2015-05-27 13:33 ` [PATCH/WIP 6/8] am: extract patch, message and authorship with git-mailinfo Paul Tan
2015-05-27 20:44   ` Junio C Hamano
2015-05-27 22:13     ` Jeff King [this message]
2015-06-03  7:56     ` Paul Tan
2015-05-27 22:13   ` Junio C Hamano
2015-06-03  7:57     ` Paul Tan
2015-05-27 13:33 ` [PATCH/WIP 7/8] am: apply patch with git-apply Paul Tan
2015-05-27 13:33 ` [PATCH/WIP 8/8] am: commit applied patch Paul Tan

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20150527221356.GE23259@peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=pyokagan@gmail.com \
    --cc=sbeller@google.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).