Re: [PATCH 4/8] rev-parse: teach "git rev-parse --symbolic" to print the full ref name
- From
Steffen Prohaska <prohaska@zib.de>
- Date
- Oct 28, 2007, 08:56 UTC
- Message-ID
- <30641295-495B-4E5E-9D44-5CAF7C480DF2@zib.de>
- In-Reply-To
- <20071028080654.GS14735@spearce.org>
On Oct 28, 2007, at 9:06 AM, Shawn O. Pearce wrote:
Show 23 quoted lines
> Steffen Prohaska <prohaska@zib.de> wrote:
>> On Oct 28, 2007, at 8:28 AM, Junio C Hamano wrote:
>>> Steffen Prohaska <prohaska@zib.de> writes:
>>>> @@ -213,6 +215,7 @@ int cmd_rev_parse(int argc, const char **argv,
>>>> const char *prefix)
>>>> {
>>>> int i, as_is = 0, verify = 0;
>>>> unsigned char sha1[20];
>>>> + char* real_name = 0;
>>>
>>> Pointer sign '*' in git sources go next to the name not the
>>> type, as:
>>>
>>> char *real_name = NULL;
>>
>> I know and I tried hard to follow this convention, although
>> I think its the wrong choice ;)
>
> Oh, hmm...
>
> char* a, b;
>
> What's the type of b? If you said "char*" you're wrong.I know. Obviously, you need a combination of conventions.
- '*' is part of the type; put it there. - Only define a single variable per statement.
My combined rule avoids your question. I typically use C++, which make the second rule easier to follow, because you defer defining variables until you really need them. There's no need to save space at the start of the function block by defining several variables in a single line.
> Git's style of putting the * next to the name makes it far easier to > spot these sort of typing problems. At least that's my take on it.
Let's stop this discussion here. I'm not proposing to change the rules. I'll follow the git coding conventions when submitting patches to git, even if it's sometimes hard for me. I already packed as much as possible in my editor configuration. Unfortunately, I can't teach vim to always place the '*' correctly. At least I don't know how to do this.
Steffen