On Tue, 2015-05-19 at 07:44 +0300, Or Gerlitz wrote:
> On 5/14/2015 8:35 PM, ira.weiny wrote:
> > On Thu, May 14, 2015 at 10:28:45AM +0300, Or Gerlitz wrote:
> >> >On Thu, May 14, 2015 at 2:20 AM,<ira.weiny@xxxxxxxxx> wrote:
> >>> > >From: Ira Weiny<ira.weiny@xxxxxxxxx>
> >>> > >
> >>> > >ib_find_send_mad only needs access to the MAD header. Change the MAD cast.
> >>> > >
> >>> > >Signed-off-by: Ira Weiny<ira.weiny@xxxxxxxxx>
> >> >
> >> >shorter and clearer subject line please, e.g
> > Sorry, I'll try to keep them brief.
>
> this isn't only on being brief, but rather of being high level and not
> carrying too many names of functions and variables, looking on the
> titles of your 4.2 patches, bunch of them are too long and down to
> details instead
> of capturing the proposed change in higher level:
>
> 6f430b IB/mad: Add const qualifiers to query only functions
Ok
> 67b3b05 IB/mad: Clean up rcv_has_same_class
Ok
> fcd6ebf IB/mad: Change ib_response_mad signature to take const
> ib_mad_hdr rather than ib_mad
IB/mad: Change ib_response_mad signature arguments
> 3b53339 IB/mad: Change validate_mad signature to take const ib_mad_hdr
> rather than ib_mad
IB/mad: Change validate_mad signature arguments
> b78d28a IB/mad: Clean up comments in smi.c
Ok
> c597eee IB/mad: Rename is_data_mad to is_rmpp_data_mad
Ok
> 81836bc IB/core: Change rdma_protcol_iboe to roce
Ok
> 6f9ab33 IB/core: Convert management helpers to core capability bits
IB/core: Convert core to use bitfield for caps
> 23ceb15 IB/core: Formalize the creation of immutable per port data
> within the ib_device object
IB/core: Add per port immutable struct to ib_device
> cb3ed7b IB/user_mad: Fix bug in ib_umad_remove_one when rdma_cap_ib_mad
> implementation changed
IB/user_mad: Fix buggy usage of port index
> 42997f2 IB/user_mad: Remove local start/end port variable and use the
> new common functions
IB/user_mad: Use new start/end port functions
> 0cf18d7 IB/core: Create common start/end port functions
Ok
>
> Maybe submit them all again with more proper commit titles? it's not too
> late, Doug, what's your
> thinking here?
I try to stick within the recommended length of git log subject as
indicated to me by vim when I'm editing my commit messages. Whatever
happens to fit inside that limit (or at least close to it, I'm not a
real stickler on it) I go with unless you really need to capture some
important detail in the subject.
However, there's no need to resubmit these. I can always edit the
subjects in place. Ira are you OK with the changes I made above?
Just to be clear though, to my knowledge, the whole reason for this is
so that git log --oneline will print out pretty output with one commit
per line. That means the maximum length of these subject messages is
limited by standard terminal width (80 columns) and the selected git
commit hash abbreviation length (which has varied due to the increasing
number of collisions in git hashes and is now set at a standard of 12
characters). So the proper length 3 years ago and the proper length
today are not the same thing. What's more, git merge commits almost
*never* fit on a single line due to the length of git urls. As a
result, our pretty --oneline output is already marred upstream by all
those merges. So do I prefer commit messages that fit on one line?
Yes. Will I demand things be resent if they don't? No. We've already
lost the war because of those merge commits, winning individual battles
now is nice, but not absolutely necessary.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: This is a digitally signed message part
