Another effort to reduce the complexity of evse.c

[taliesin]

I tried to reduce evse_process() to as small as possible in order to keep the actual change for the phase switching as consistent as possible. I've tried to make consistent change sets.

[taliesin]

I think it would be better not to squash the commits when merging the pull request. This will make bi-secting a lot harder if a bug shows up.

[dzurikmiroslav]

Ok i'll think about it. Squash commit was default github option...

[taliesin]

Thx for merging.

I just updated to your latest changes. Concerning your merge I'd like you to consider rebasing your own changes to an updated master after you integrate a pull request. Currently this creates a non-fast-forward merge which again will hinder bisecting efforts.

Don't want to be a smart-ass, but you just added a PULL_REQUEST_TEMPLATE.md which exactly states that :)

[dzurikmiroslav]

I don't even know exactly how I managed to merge :D In PULL_REQUEST_TEMPLATE.md I wanted to mention that the code must be formatted to pass CI.

[taliesin]

Ok, no problem. The main topic is how to create fast forward merges, i.e. merges that to do not create parallel lines in your history. The way to go is 'rebasing', there is a nice tutorial on git rebase here https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase

Long story short, the usual git way is:

• create a feature branch where you put your commits: git checkout -b "feature/my_cool_feature"
• when done pull the potentially new master (i.e. one where you merged a pull request): git checkout master; git pull origin master
• your feature branch now sits on an older commit, to have that rebased to the current master: git checkout feature/my_cool_feature; git rebase master
• this way your branch is put on top of the changed master
• fix the conflicts (you are given that opportunity interactively by the rebase command)
• when all conflicts are resolved, you may merge your feature branch into master (doing a fast forward merge).

Take care: rebasing changes the history of your commits, this may (and most probably will) create conflicts, if you change already changed files. This is a great way to kill your commits :-) I usually create a backup branch before I rebase, git checkout feature/my_cool_feature; git checkout -b rebase_backup. This way you have a backup if you completely mess up your rebasing.

VS code offers a nice GUI (Gitlens) that also allows a guided rebasing mechanism. I'm more the command line gui, though. I recommend you test your rebasing capabilities on a non-production-repo, by simply creating 2 separate test feature branches and trying to merge them (including conflicts) in a fast forward way.