Re: Renaming .c files to .cc?
"Christian Biesinger via gdb" <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CAPTJ0XG6FtH-7Jy8rN4K+pQmwkJ5AZ1q-StVmqoSxMGgH-KjsA@mail.gmail.com> |
On Tue, Dec 10, 2019 at 7:41 PM Luis Machado <[email protected]> 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.: $ 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. > 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 > >