Hello all,
The main problem with adopting style checkers so late in a project’s life is that they usually introduce really vast changes. You practically end up with a huge commit that touches each and every python file. Needless to say this makes using e.g. git blame much much harder.
If you want to test it out, please try the following from a clean state:
cd lib/python
git status # make sure that no files have any changes in lib/python
black --exclude OBJ ./
git diff --patience --minimal ./ | wc -l
That’s a 75k+ line diff and that’s only the “grass” library. The gui should give something similar.
To restore the repo, just run:
git checkout ./
That being said, I do use black in practically all my new projects, usually applying it via pre-commit, and it works great, but I am not sure if it is truly an option for GRASS.
all the best,
P.
On Wed, May 29, 2019 at 4:07 AM Panagiotis Mavrogiorgos <pmav99@gmail.com> wrote:
The main problem with adopting style checkers so late in a project’s life is that they usually introduce really vast changes. You practically end up with a huge commit that touches each and every python file. Needless to say this makes using e.g. git blame much much harder.
This already happened in the past:
C
https://trac.osgeo.org/grass/changeset/32526
286,279 additions and 272,386 deletions
Python
https://trac.osgeo.org/grass/changeset/68374
47,846 additions and 34,489 deletions
On Thu, May 30, 2019 at 1:14 AM Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Wed, May 29, 2019 at 4:07 AM Panagiotis Mavrogiorgos <pmav99@gmail.com> wrote:
The main problem with adopting style checkers so late in a project's life is that they usually introduce really vast changes. You practically end up with a huge commit that touches each and every python file. Needless to say this makes using e.g. git blame much much harder.
This already happened in the past:
C
https://trac.osgeo.org/grass/changeset/32526
286,279 additions and 272,386 deletions
In 2006, there was another major change in the C code (with months of
preparation):
ANSIfication of GRASS C functions (automated reformatting from K & R C
to ANSI C):
https://lists.osgeo.org/pipermail/grass-dev/2006-January/020767.html
- https://trac.osgeo.org/grass/changeset/18618,
https://trac.osgeo.org/grass/changeset/18619
- https://trac.osgeo.org/grass/changeset/18623,
https://trac.osgeo.org/grass/changeset/18625
- https://trac.osgeo.org/grass/changeset/18626,
https://trac.osgeo.org/grass/changeset/18627
- https://trac.osgeo.org/grass/changeset/18628,
https://trac.osgeo.org/grass/changeset/18632
- https://trac.osgeo.org/grass/changeset/18633
Related scientific publication:
A Feedback Based Quality Assessment to Support Open Source Software
Evolution: the GRASS Case Study
https://www.researchgate.net/publication/224674480_A_Feedback_Based_Quality_Assessment_to_Support_Open_Source_Software_Evolution_the_GRASS_Case_Study
(btw: I didn't find these changesets in the git commit list)
Python
https://trac.osgeo.org/grass/changeset/68374
47,846 additions and 34,489 deletions
best,
Markus
--
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://courses.neteler.org/blog