Re: [PATCH] gnulib-tool.py: Append, don't replace existing VCS ignore files

[Darshit Shah]

Hi Bruno,

> Hi Darshit,
> 
> > * pygnulib/GLImport.py(_update_ignorelist_): Append the ignore data to
> > any existing VCS ignore files instead of replacing them
> 
> We cannot judge this patch, for lack of information about what it does and
> why it is needed.

Sorry, I meant to have a detailed description sent along with the patch,
but I guess I forgot to add the cover-letter in my command. Hence, let
me explain it here

> 
> 1) What is the problem with the current behaviour of gnulib-tool.py?
> 
With the existing behaviour, gnulib-tool.py will replace the old VCS
ignore file (.gitignore in the case of Wget2) with a list it created
internally. Hence, on a fresh checkout of Wget2 which now uses
gnulib-tool.py as the gnulib driver, when one executes "./bootstrap",
the existing `.gitignore` file in the project is replaced with one
created by gnulib-tool.py, removing all the ignore rules set by the
project for that repository.

On top of it, there is another bug which I have not yet managed to nail
down. That is, it tries to update "tests/.gitignore" twice. First, with
a list of new files that it has created, and then again with an empty
list. With the existing behaviour, it creates a new "tests/.gitignore"
file and then replaces it with an empty file as a result.

My patch fixes both these cases, however it does not fix the bug where
"tests/.gitignore" is created and then updated in the same run. Neither
does it fix the issue I raised in a different email to this list about
gnulib-tool.py creating new files in the "tests/" directory.
>
> 2) Is the behaviour of gnulib-tool the same? That is, is this patch 
> introducing
>    a behavioural difference between gnulib-tool.py and gnulib-tool, or is it
>    removing one?
> 
As explained above, this patch helps converge gnulib-tool.py and
gnulib-tool. There is a behavioural difference which I also consider to
be a regression, and hence a string need to fix it.

> Some background: We plan to have, for some time, gnulib-tool and 
> gnulib-tool.py
> be functionally identical, i.e. they should produce the exactly same results
> and outputs. During this time,
>   - Dmitry and others will be able to rewrite or optimize gnulib-tool.py,
>   - Anyone can compare the results and speed of gnulib-tool vs. 
> gnulib-tool.py.
> 
> But we are not there yet. Maybe in one or two weeks, but not now. Until then,
> it is essential that gnulib-tool.py *converges* to gnulib-tool. We want to
> avoid diverging behaviour.
> 
> And when we are there, it will be essential that gnulib-tool.py and 
> gnulib-tool
> evolve in sync. That is, any new feature of gnulib-tool should be a new
> feature of gnulib-tool.py, and vice versa.
> 
I understand this very well. I've been following the mailing lists and
the development of gnulib-tool.py. Dmitry's work with the Python script
has been great and this definitely helps in reducing the time it takes
to run bootstrap on a fresh checkout.

-- 
Thanking You,
Darshit Shah
PGP Fingerprint: 7845 120B 07CB D8D6 ECE5 FF2B 2A17 43ED A91A 35B6

signature.asc
Description: PGP signature