On 20/07/2020 12:21, Scott Branden via mbed-tls wrote:
Although this particular change doesn't affect me - rewriting history is a bad idea.
Why not simply commit a revert back to a cleaner point on "master" branch and then commit the new changes you want from there?
Then history is not lost on master branch.
Mbed TLS used to follow the Git Flow model: day-to-day work happens on the 'development' branch, and there's a 'master' branch which always points to the latest commit on master that's a tagged release. A release is done by tagging a commit on 'development' and fast-forwarding 'master' to it.
But after the 2.16 LTS release, we made 'master' follow the 2.16 LTS branch rather than 'development'. I think this was a mistake, but it's too late to change this, the question is what we do now with the existing situation.
A force-push on 'master' would not erase history from the face of the world. The history is still there in 'mbedtls-2.16'.
It is no longer possible to fast-forward 'master' to any commit on 'development'. No amount of revert or merge commits on 'master' will make it be the same commit as some a release made from 'development'. Without a force-push, all we can hope is to have 'master' have the same content as a release. This means that getting the same release would give you the same content, but different history, depending on whether tyou get it from 'master' or 'development'. This would also mean a more complicated release process.
Another solution would be to do a merge of 'master' into 'development', ignoring all changes from the 'master' side. But this would mess up the history on 'development'.
Is this more complicated release process, or this messy history, worth it, just to avoid a force-push?
Or, with the BLM movement some repos are stopping use of master branch. github seems to be encourage it going forware: https://www.zdnet.com/article/github-to-replace-master-with-alternative-term...
So another option: stop using "master" branch. You could even create a tag/rename and then delete the branch name to avoid any confusions. History won't be rewritten then, just a little "hidden". And start using a new "main" branch. You can push you entire commit series there without revering anything on master branch.
Sure, we can create a new branch name. But then we'd still have to keep a branch with the old name, for the sake of existing setups that pull from 'master'. Or else we should make a commit on 'master' that removes every file and instead adds a README that says "pull from 'main' instead".