Re: [PATCH] commit.c:record_author_date() use skip_prefix() instead of starts_with()
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/