On 1/13/22 11:47, Martin Jambor wrote:
Hi,

On Tue, Jan 11 2022, Martin Liška wrote:
Hello.

I've got a patch series that does the renaming. It contains of 2 automatic
scripts ([1] and [2]) that were run as:

$ gcc-renaming-candidates.py gcc --rename && git commit -a -m 'Rename files.' && 
rename-gcc.py . -vv && git commit -a -m 'Automatic renaming'

The first scripts does the renaming (with a couple of exceptions that are 
really C files) and saves
the renamed files to a file. Then the file is then loaded and replacement of 
all the renamed files does happen
for most of the GCC files ([2]). It basically replaces at \b${old_filename}\b 
with ${old_filename}c
(with some exceptions). That corresponds to patch #1 and #2 and the patches are 
quite huge.

The last piece are manual changes needed for Makefile.in, configure.ac and so 
on.

The git branch can be seen here:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/cc-renaming

and pulled with:
$ git fetch refs/users/marxin/heads/cc-renaming
$ git co FETCH_HEAD


Thanks for the effort!  I looked at the branch and liked what I saw.

Thanks.

Perhaps only a small nit about the commit message of the 2nd commit
("Automatic renaming of .c files to .cc.") which confused me.  It does
not actually rename any files so I would change it to "change references
to .c files to .cc files" or something like that.

Sure, I'm going to update the commit message.


But I assume the branch will need to be committed squashed anyway, so
commit message worries might be a bit premature.

No, I would like to commit it as 3 separate commits for this reasons:
- git renaming with 100% match should guarantee git would fully work with 
merging and stuff like that
- I would like to distinguish manual changes from these that are only a 
mechanical replacement.

Cheers,
Martin


I am looking forward to seeing it in trunk.

Martin

Reply via email to