Re: Renaming .c files to .cc?

[Luis Machado <luis.machado@linaro.org>]

On 12/10/19 10:26 PM, Christian Biesinger wrote:
> On Tue, Dec 10, 2019 at 7:41 PM Luis Machado <luis.machado@linaro.org> wrote:
>>
>> On 12/10/19 7:18 PM, Christian Biesinger via gdb wrote:
>>> Hello all,
>>>
>>> I was wondering what people's thoughts are on renaming the .c files to
>>> .cc, since they are in fact C++ code? (Only for files under gdb/)
>>
>> I don't have strong objections to this other than it may make things
>> slightly more tedious to 'git blame' some files, as Tromey pointed out.
> 
> Can you elaborate on that? git blame seems to work as expected for this, e.g.:

I had not given this a try and was assuming it would just reset all the 
lines to the commit that renamed the file. Looks like it is smart enough 
to keep the change ids in there (checked now).

So this is a non-issue for me.

> $ git blame gdbsupport/gdb_string_view.h
> 7adcdf08e792 gdb/common/gdb_string_view.h     (Simon Marchi
> 2018-04-09 13:31:04 -0400   1) // Components for manipulating
> non-owning sequences of characters -*- C++ -*-
> 7adcdf08e792 gdb/common/gdb_string_view.h     (Simon Marchi
> 2018-04-09 13:31:04 -0400   2)
> 1a5c25988eab gdb/common/gdb_string_view.h     (Tom Tromey
> 2019-01-27 12:51:36 -0700   3)
> 1a5c25988eab gdb/common/gdb_string_view.h     (Tom Tromey
> 2019-01-27 12:51:36 -0700   4) #ifndef COMMON_GDB_STRING_VIEW_H
> 1a5c25988eab gdb/common/gdb_string_view.h     (Tom Tromey
> 2019-01-27 12:51:36 -0700   5) #define COMMON_GDB_STRING_VIEW_H
> ...
> 700545387df8 gdb/gdbsupport/gdb_string_view.h (Christian Biesinger
> 2019-10-01 13:36:07 -0500  49) #include "gdb_assert.h"
> 
> And git log has the --follow option for this purpose.
> 

That's good to know.

>> But i think that is excusable compared to better organization of source
>> files, for what they really are (C++ files).
>>
>>>
>>> Advantages:
>>> - Easier for newcomers to see that the code is, in fact, C++
>>> - Editors will syntax highlight C++ keywords w/o having to be told
>>> that these files are C++
>>
>> The above items sound like reasonable pluses.
>>
>>>
>>> On IRC it was mentioned that git may have issues with renames like
>>> that but I have found that "git log --follow" and such are doing a
>>> good job with that, at least as long as the same commit doesn't change
>>> the file too much while it is renamed, which I wouldn't expect to be a
>>> problem here.
>>>
>>> Thoughts?
>>> Christian
>>>