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

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

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

Reply via email to