Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 69.

[Bruno Haible]

Hi Collin,

> This patch should hopefully stop gnulib-tool.py from mangling
> .gitignore files like it did previously. I think I did a decent job
> translating the join calls into Python sets, but any criticism is
> welcome.

I've applied the patch, although it is incomplete.

Next, I applied the attached renaming of variables; the previous variable
names made it hard to understand what's going on.

What's still missing, is the handling of 'files_removed'.
GLImport.py lines 804..820 ought to match gnulib-tool.sh lines 6253..6273.

> In the test case:
> $ find . -name .gitignore~ -type f -print
> ./import-tests/test-coreutils-1.result/.gitignore~
> ./import-tests/test-wget2-1.result/.gitignore~
> 
> Should these files be removed?
> 
> diff --git a/gnulib-tool-tests/init.sh b/gnulib-tool-tests/init.sh
> index c3625ca..27c4818 100644
> --- a/gnulib-tool-tests/init.sh
> +++ b/gnulib-tool-tests/init.sh
> @@ -133,6 +138,10 @@ do_import_test ()
>    if test -n "$build_aux_dir"; then
>      rmdir $build_aux_dir
>    fi
> +  gitignores=`find $tmp-result -name '.gitignore~' -type f -print`
> +  if test -n "$gitignores"; then
> +    rm $gitignores
> +  fi
>    # Remove autom4te.cache directory, since it may depend on the Autoconf 
> version or M4 version.
>    rm -rf $tmp-result/"$2"/autom4te.cache
>    if test $rc != 0; then

No, no. This would be wrong. The principle is: Each time gnulib-tool
modifies a file that is/was not entirely autogenerated, a backup copy
is created. (We do *not* assume that the developer had used version control.)
'.gitignore' files obviously are owned by the developer, so must be backed up
when modified.

Bruno

0001-gnulib-tool.py-Refactor.patch
Description: Text Data