Re: [PATCH] commit.c:record_author_date() use skip_prefix() instead of starts_with()

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Mar 3, 2014, 08:58 UTC
Message-ID: <53144450.3080006@alum.mit.edu>
In-Reply-To: <1393703299-7977-1-git-send-email-tanayabh@gmail.com>

The format of this email is wrong. The non-commit-message notes should come between the "---" line (<- note, there are three minus signs here) and the patch itself.

On 03/01/2014 08:48 PM, Tanay Abhra wrote:

Show 15 quoted lines

> Signed-off-by: Tanay Abhra <tanayabh@gmail.com>
> ---
>  commit.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/commit.c b/commit.c
> index 6bf4fe0..c954ecb 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -566,7 +566,7 @@ static void record_author_date(struct author_date_slab *author_date,
>  	     buf;
>  	     buf = line_end + 1) {
>  		line_end = strchrnul(buf, '\n');
> -		if (!starts_with(buf, "author ")) {
> +		if (!skip_prefix(buf, "author ")) {

If this is the only change, there is not much point, is there? How does this help? Perhaps there is some way to take advantage of the difference between starts_with() and skip_prefix() to simplify the rest of the function?

Show 23 quoted lines

>  			if (!line_end[0] || line_end[1] == '\n')
>  				return; /* end of header */
>  			continue;
> -- 
> 1.7.9.5
> 
> Hello,
> 
> This is my patch for the GSoC microproject #10:
> 
> Rewrite commit.c:record_author_date() to use skip_prefix(). 
> Are there other places in this file where skip_prefix() would be more 
> readable than starts_with()?
> 
> Since skip_prefix() and starts_with() implement the same functionality with different
> return values, they can be interchanged easily.
> 
> Other usage of starts_with() in the same file can be found with
> 
> $ grep -n starts_with commit.c
> 
> 1116:		else if (starts_with(line, gpg_sig_header) &&
> 1196:		if (starts_with(buf, sigcheck_gpg_status[i].check + 1)) {

The rhetorical question that was part of this microproject was meant to inspire you to actually *FIX* the other spots, at least if the change makes sense.

> I have a query,should I tackle a bug from the mailing lists or research about the proposal 
> and present a rough draft?

My suggestion is that you follow up on this microproject until it is perfect before worrying too much about the next step.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/