On Wed, Apr 15, 2015 at 2:09 AM, Trevor Saunders <tbsau...@tbsaunde.org> wrote:
> On Tue, Apr 14, 2015 at 10:46:19AM +0200, Richard Biener wrote:
>> On Tue, Apr 14, 2015 at 7:20 AM, Trevor Saunders <tbsau...@tbsaunde.org> 
>> wrote:
>> > Hi!
>> >
>> > To be clear I only want to talk about gcc/**/*.c but *not* testsuite/
>> >
>> > The Question of changing from .c to a more standard C++ file extension
>> > has come up a couple times.  I believe its reasonable accurate to say
>> > the consensus is moderately in favor of doing this at some point.  The
>> > biggest concern was of course being able to access pre rename history
>> > easily.  I know git will either handle this by default or with an option
>> > depending on the command, and svn claims it can handle renames so we
>> > should be good on that front.  The other question was if we should wait
>> > to do this at the same time as a reorganization of directory structure.
>> > That was back in august 2013, about a year and a half ago, and we
>> > haven't done it or really moved forward with a plan to do it.  It seems
>> > to me that if we do this part now we can then deal with moving files
>> > into directories later piece by piece and not need to move everything at
>> > once.  If we want to go ahead with renaming we should pick a time, I
>> > think some people have advanced the idea of doing it just after a
>> > branch, on the other hand last year we held off on the big gimple
>> > refactoring until after the branch had released a .1.
>> >
>> > thoughts?
>>
>> I see no value in doing this but making branch maintainance awkward.
>
> I think its mostly valuable to cause less confusion of new people, and
> though it is a simpler thing every little thing can be the thing that
> breaks the cammel's back.

I don't buy this kind of argument given that the switch to C++ has
complicated things instead of simplifying them.

> Yes its not all that hard to configure
> editors and what not to handle it properly, but every new person needs
> to do it, and looking up configuration options takes time that can more
> profitably be spent.
>
> That said keeping backports as easy as possible is also certainly
> important.  I'm curious why renames hurt doing backports, I'm pretty
> confident git cherry-pick will handle it for you, and if you like patch
> files for some reason I'd think its easy to fix up with sed though
> running that for each backport by hand would get a little old.

So if git can simplify the issues then the appropriate time to do this
mass rename is when we switch to git.

Richard.

>
> Trev
>
>>
>> Richard.
>>
>> > Trev

Reply via email to