Squash history of changes from 4.0.0

[mmatera]

In the branch rebase-from-400, I tried to squash changes from the tag 4.0.0 (I mean, removing merge, black, and lint commits). That was not too hard (I just find a couple of conflicts with the changes in setup.py). Does it make sense to do this over the master branch?

[TiagoCavalcante]

@mmatera thanks for doing this! I think makes sense to do this in master.

[TiagoCavalcante]

@mmatera the latest commit from the master branch was leaking, I committed that. I checked the difference between your branch and master, there's only one different formating in a test, except that, everything is correct.

As this is a rebase, this can't be merged. The commands I recommend to push this are:

git checkout master
git pull
git checkout -b master-backup origin/master # create a backup of the master branch
git checkout rebase-from-400
git branch -D master # delete the master branch, bit keeps the backup
git branch -m master # rename the branch rebase-from-400 to master
git push -f origin/master

[mmatera]

@TiagoCavalcante, thanks. I imagined that the procedure was something like you said. Let's try to see if there is something more to squash before doing this risky step, and if we all agree, let's do it.

[rocky]

I am for reducing the massive amount of low level noise that is constantly going on. If while you are at it, increase useful descriptive information in commit messages.

[mmatera]

@rocky, OK, we agree on that, but what I ask about is a different question: what should we do with the noise that we already had introduced?

[rocky]

squash commits like "merge" within a branch (not a real PR merge) and "remove debug statement" and the multiple attempts to get CI working, and introduction of debug statements and testing commits.