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
