[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] gnulib-tool.py: Append, don't replace existing VCS ignore fi
Re: [PATCH] gnulib-tool.py: Append, don't replace existing VCS ignore files
Mon, 11 Sep 2017 14:30:20 +0200
> 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
> 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
> 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.
> 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
> 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.
PGP Fingerprint: 7845 120B 07CB D8D6 ECE5 FF2B 2A17 43ED A91A 35B6
Description: PGP signature