[sr-dev] rfc: clang format the code

Daniel-Constantin Mierla miconda at gmail.com
Fri Nov 24 08:55:57 CET 2017


Hello Henning,

indeed, git blame is not going to show directly the original author...
as I wanted to see if there is a solution for this, I found:

  - https://blog.andrewray.me/a-better-git-blame/

and actually a comment there seems to be a decent solution to go back in
the history of the commits to find the author, pasting it here:

> Just use `git gui blame -- path/to/file.ext` followed by right click
and `Do full copy detection`.
> Scroll to line you want to investigate and see the commit message. If
it looks like it's not the commit
> you're interested in, right click the line you're really interested in
and select `Blame parent commit`.
> Doing it this way allows you to find the whole history of that line
even if it came from another file.

Also, we lost the direct seeing of the commit log for some files when we
relocated code for 5.0 release, therefore now git log needs to be used
--follow flag if one wants to track back to the origin. I added aliases
in my gitconfig to make it shorted to work with:

      logf = log --follow
      logfp = log -p --follow
      logpf = log -p --follow

Cheers,
Daniel

On 24.11.17 08:39, Henning Westerholt wrote:
> Am Donnerstag, 23. November 2017, 17:20:48 CET schrieb Daniel-Constantin 
> Mierla:
>> it was discussed during the last irc devel meeting and everyone there
>> agreed to use clang-format to format the source code:
>>
>>   - https://clang.llvm.org/docs/ClangFormat.html
>>
>> Is any developer (maybe not present during the irc devel meeting)
>> opposing this?
>> [explanation of motivation]
> Hello Daniel,
>
> I think there is only (small) downside of a thorough re-formatting of the code 
> like this: It makes manual bug triage with git blame more difficult, as git 
> blame shows only the last commit in a line.
>
> Therefore its important that this changes are applied as one dedicated commit 
> per module, not mixed with other functional changes (exactly as you proposed).
>
> The advantages of a consistent style in all modules are much greater than this 
> downside, I have nothing against this change.
>
>> If no one shows anything against in a matter of few days, it will be
>> considered accepted (after all, one can re-indent on own style if the
>> rule is not accepted or overturned).
> Best regards,
>
> Henning

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com




More information about the sr-dev mailing list