On Monday, July 3, 2017 at 3:44:10 PM UTC-5, Terry Brown wrote: > > Anyway, as long as no one uses git push --force, I don't think it's > possible to lose anything. >
Right. We can't do that. This page <https://stackoverflow.com/questions/4114095/how-to-revert-git-repository-to-a-previous-commit> discusses the problems with trying to undo commits that have been pushed and then pulled by others. Rev 3a9e54e reverts *almost* everything to 5c25d3f, the last commit before everything went weird. The only real omission was the recent changes to quicksearch.py. I performed this restoration as follows: - git checkout 5c25d3f # the "good" commit - load leoPy.leo - git checkout master: Do NOT reload files into leoPy.leo. - write all files from leoPy.leo - test - add, commit and push In other words, I used leoPy.leo as a source of the desired code. It's a bit unorthodox, but it seems to have worked fine. I think master is ready to pull and test. The big question is, how to make sure the present master code forms the basis of important branches? I'm not sure that a merge from master to sqlite-format will do the trick. In other words, I suspect that sqlite-format is dangerous, through no fault of Vitalije. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
