Re: [PATCH] Removed unnecessary void* from hashmap.h that caused compile warnings

From: Thomas Gummerer <t.gummerer@gmail.com>
Date: Jan 15, 2018, 23:59 UTC
Message-ID: <20180115235943.GM2641@hank>
In-Reply-To: <007801d38e42$6b6df3b0$4249db10$@nexbridge.com>

On 01/15, Randall S. Becker wrote:

Show 38 quoted lines

> On January 15, 2018 3:43 PM, Thomas Gummerer wrote:
> > Thanks for your patch!  A few nitpicks below:
> > 
> > > Subject: [PATCH] Removed unnecessary void* from hashmap.h that caused
> > > compile warnings
> > 
> > From Documentation/SubmittingPatches:
> > 
> >     Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
> >     instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
> >     to do frotz", as if you are giving orders to the codebase to change
> >     its behavior.
> > 
> > I liked the subject Philip suggested in the other thread: "hashmap.h:
> > remove unnecessary void*", or maybe "hashmap.h: remove unnecessary
> > variable".
> > 
> > On 01/14, randall.s.becker@rogers.com wrote:
> > > From: "Randall S. Becker" <rsbecker@nexbridge.com>
> > >
> > > * hashmap.h: Revised the while loop in the
> > hashmap_enable_item_counting
> > > 	to remove unneeded void* item.
> > 
> > As above, this should be described in an imperative mood, and describe why
> > this is a good change and should be merged.  Maybe something along the
> > lines of the below?
> > 
> >     In 'hashmap_enable_item_counting()', item is assigned but never
> >     used.  This causes a warning on HP NonStop.  As the variable is
> >     never used, fix this by just removing it.
> > 
> > > Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com>
> > >
> > > [..snip..]
> > >
> I like it. Do you need this resubmitted? Or should I just learn for next
> time?

I think it would be good if you resubmit the patch. These rules tend to be applied quite strictly, as you can also see when looking at the git commit history. So with the updated commit message Junio should just be able to pick it up (unless there's something I missed here as well :))

As a side note, I just noticed the two submissions both had [PATCH] in the title, whereas new submissions should be marked as such using [PATCH v2] etc. as prefix, so it's easier for reviewers to know which version is the newer one.

> Cheers,
> Randall
>