Renaming .c files to .cc?

Renaming .c files to .cc?

[Christian Biesinger via gdb]

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/)

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++

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

Re: Renaming .c files to .cc?

[Luis Machado]

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.

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
> 

Re: Renaming .c files to .cc?

[Christian Biesinger via gdb]

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.:
$ 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
> >

Re: Renaming .c files to .cc?

[Luis Machado]

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
>>>

Re: Renaming .c files to .cc?

[Simon Marchi]

On 2019-12-10 5:18 p.m., 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/)
> 
> 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++
> 
> 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

Given that git makes it possible to browse the history across the file rename,
I would vote for renaming, so that we are not stuck with this oddity for eternity.

Simon

Re: Renaming .c files to .cc?

[Eli Zaretskii]

> From: "Christian Biesinger via gdb" <gdb@sourceware.org>
> Date: Tue, 10 Dec 2019 17:18:58 -0500
> 
> 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.

Not every Git command has a --follow option, so renaming files does
have disadvantages in that area.

Also, even with --follow, Git's tracking of renaming is heuristics,
so it can fail.

Re: Renaming .c files to .cc?

[Pedro Alves]

On 12/10/19 10: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/)
> 
> 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++
> 
> 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?
My thoughts are that using .c instead of .cc is largely a minor
aesthetic issue, and that of all the things that might hinder someone
from seriously contributing to gdb, this has got to be at the bottom
of the list.  It's one of those things that you might be surprised about,
and then once you learn it, it just fades into the background and you
barely remember it.  We could just document it in some easier-to-find
place to eliminate the "surprise" effect and call it a day.
OTOH, renaming all the files has a recurring cost to people using git
tooling every day.

IMO, renaming the files has a disproportionate cost/benefit ratio.
I'm not terribly opposed, but I'm in the "prefer not" camp.

Thanks,
Pedro Alves

Re: Renaming .c files to .cc?

[Eli Zaretskii]

> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 11 Dec 2019 10:59:07 +0000
> 
> IMO, renaming the files has a disproportionate cost/benefit ratio.
> I'm not terribly opposed, but I'm in the "prefer not" camp.

FWIW, I'm in the same camp (although my opinion's weight is much lower
than Pedro's, as I get/need to work with GDB's Git much less than he
does).

Re: Renaming .c files to .cc?

[Christian Biesinger via gdb]

On Tue, Dec 10, 2019 at 10:32 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: "Christian Biesinger via gdb" <gdb@sourceware.org>
> > Date: Tue, 10 Dec 2019 17:18:58 -0500
> >
> > 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.
>
> Not every Git command has a --follow option, so renaming files does
> have disadvantages in that area.

Do you have a specific command in mind that doesn't? I haven't come
across that yet myself.

> Also, even with --follow, Git's tracking of renaming is heuristics,
> so it can fail.

Technically correct, but not an issue in practice when files are being
renamed without changes, like they would be here.

Christian

Re: Renaming .c files to .cc?

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Wed, 11 Dec 2019 17:59:39 -0500
> Cc: gdb@sourceware.org, Pedro Alves <palves@redhat.com>
> 
> > Not every Git command has a --follow option, so renaming files does
> > have disadvantages in that area.
> 
> Do you have a specific command in mind that doesn't? I haven't come
> across that yet myself.

Are you saying that every Git command supports that option?  I don't
think so.

And even those who do support it impose limitations when it's used.
For example,

  $ git log file1 file2 ...

works, but

  $ git log --follow file1 file2 ...

fails with an error message.  So many important forensic
investigations limit you to single files when using --follow.

> > Also, even with --follow, Git's tracking of renaming is heuristics,
> > so it can fail.
> 
> Technically correct, but not an issue in practice when files are being
> renamed without changes, like they would be here.

That's not guaranteed, because several files with similar contents can
dupe the heuristics.

Anyway, like Pedro said: the reasons for being in the "rather not"
camp are not strong.

Re: Renaming .c files to .cc?

[Christian Biesinger via gdb]

On Thu, Dec 12, 2019 at 1:17 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Christian Biesinger <cbiesinger@google.com>
> > Date: Wed, 11 Dec 2019 17:59:39 -0500
> > Cc: gdb@sourceware.org, Pedro Alves <palves@redhat.com>
> >
> > > Not every Git command has a --follow option, so renaming files does
> > > have disadvantages in that area.
> >
> > Do you have a specific command in mind that doesn't? I haven't come
> > across that yet myself.
>
> Are you saying that every Git command supports that option?  I don't
> think so.

Sorry, that's not what I meant; I had never run into one where I
missed that option, and you sounded like you had one in mind, so I was
curious. I don't know either way if there are git commands that miss
that option.

BTW, there is a setting to make --follow the default. git config
--global log.follow true

> And even those who do support it impose limitations when it's used.
> For example,
>
>   $ git log file1 file2 ...
>
> works, but
>
>   $ git log --follow file1 file2 ...
>
> fails with an error message.  So many important forensic
> investigations limit you to single files when using --follow.

OK.

> > > Also, even with --follow, Git's tracking of renaming is heuristics,
> > > so it can fail.
> >
> > Technically correct, but not an issue in practice when files are being
> > renamed without changes, like they would be here.
>
> That's not guaranteed, because several files with similar contents can
> dupe the heuristics.
>
> Anyway, like Pedro said: the reasons for being in the "rather not"
> camp are not strong.

OK, I'll drop this.

Christian