24 Nov
2017
24 Nov
'17
8:55 a.m.
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:
--
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
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