On Thu, May 9, 2013 at 6:12 PM, Felipe Contreras <felipe.contre...@gmail.com> wrote: > On Thu, May 9, 2013 at 6:09 PM, Junio C Hamano <gits...@pobox.com> wrote: >> John Szakmeister <j...@szakmeister.net> writes: >> >>> On Wed, May 8, 2013 at 9:16 PM, Felipe Contreras >>> <felipe.contre...@gmail.com> wrote: >>>> Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com> >>>> --- >>>> builtin/fast-export.c | 24 ++++++++++++------------ >>>> 1 file changed, 12 insertions(+), 12 deletions(-) >>>> >>>> diff --git a/builtin/fast-export.c b/builtin/fast-export.c >>>> index d60d675..8091354 100644 >>>> --- a/builtin/fast-export.c >>>> +++ b/builtin/fast-export.c >>>> @@ -135,7 +135,7 @@ static void export_blob(const unsigned char *sha1) >>> [snip] >>>> @@ -289,13 +289,13 @@ static void handle_commit(struct commit *commit, >>>> struct rev_info *rev) >>>> parse_commit(commit); >>>> author = strstr(commit->buffer, "\nauthor "); >>>> if (!author) >>>> - die ("Could not find author in commit %s", >>>> + die("Could not find author in commit %s", >>>> sha1_to_hex(commit->object.sha1)); >>> >>> It looks like your simple replace didn't account for calls with >>> multiple lines. Now the remaining lines don't line up. >>> :-) There's several more places like this in the patch. >> >> Good eyes. >> >> Matching the coding-style to have no SP between function name and >> its argument list is just as important as matching the indentation >> style used in the project; trading one breakage with another does >> not make much sense. > > Where exactly in Documentation/CodingGuidelines is the "indentation > style" used in the project specified that is being violated?
I find it extremely annoying that an obviously correct patch is not merged because it's not conforming to a non-existing coding-style guideline that not even the Linux project follows. I've sent many patches where I change the alignment from cino=(0, to cino=(2s, and the get applied because if it's not mentioned in Documentation/CodingStyle, it cannot be used as a reason for rejection. I fixed the style so it conforms to Documentation/CodingGuidelines, and nowhere in there is the open parenthesis alignment mentioned, so using that as a reason to reject this patch is a mistake in my opinion. If you prefer the code to not follow Documentation/CodingGuidelines, so be it. I'm not going to work on this patch any more. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html