On Thu, May 9, 2013 at 1:38 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
>>>> if (!author)
>>>> - die ("Could not find author in commit %s",
>>>> + die("Could not find author in commit %s",
>>> 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.
>> AFAIK neither the git or the Linux code-style specify how multiple
>> lines with open parenthesis should align.
> Then the usual "follow the style of surrounding code" rule would
> apply, no?
The surrounding code has all the open parentheses wrong for these
functions, that doesn't mean the surrounding code is correct.
> It is clear that the original wants to align the opening
> dq of "Could..." and 's' at the beginning of sha1_to_hex().
> Why is it so hard for you to say "Good eyes, thanks"?
Because I didn't miss it, it was deliberate from my side, if nobody
can be bothered to add a rule on the coding style guidelines, why
should I bother? As I said, this pops up from time to time in Linux
mailing lists, but at the end of the day the CodingStyle doesn't
specify what should be the way to align these, so any discussion about
whether they are properly aligned or not is futile.
If it was up to me, I would use the alignment that makes more sense,
which is to align two tabs always, this way, each time somebody
decides to change the first line, the rest of the lines don't need to
change, which is something I see through the CodingStyle; try to avoid
a style that would generate bigger diffs.
But if I did such alignment I might create even more discussion, so I
deliberately decided not to change the alignment at all, which still
leaves the code in accordance with the CodingStyle.
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