Cherry-pick warning

[JoFrhwld]

FYI @chrisbrickhouse and @DerMoehre, as the ones most actively sending PRs and making commits rn, something wonky's gone down with my feature/parselmouth and feature/newdocs branches. Not sure what's going on, but I've got some identical commits in the history of these branches to dev/ but with different hashes. causeing some issues that I'm going to try to sort out.

[chrisbrickhouse]

Hmm, I tried to do a quick rebase and it's quite a mess. I'll take a closer look later this evening, but I'm guessing some combination of rebase -i and squash will be helpful.

[JoFrhwld]

I have no idea what caused this, but I created a new parselmouth-fix branch and cherry-picked the relevant commits, and it's (mostly) cleaned up there.

[chrisbrickhouse]

My guess is a ton of conflicts in poetry.lock, that's what I ran into while rebasing. We should probably figure out a better workflow for merging updated poetry.lock files. I did some searching and it seems the main pattern is to atomize lock file commits: if a commit includes a change to poetry.lock, then that should be the only change in that commit. That way, when we go to resolve conflicts, it's just that commit that one conflict which needs resolved, the rest can be fast-forwarded.

[JoFrhwld]

A warning again, I'm going to be cherrypicking commits out of feature/docs and feature/newdocs into feature/doc-fix to see if I can't make a clean branch

[DerMoehre]

I Hope, that I did not do any damage by mistake.
I commited to dev, but maybe I am using the wrong command with git add . ? Ist there a better way?

[JoFrhwld]

Oh, this was definitely a me issue , not anyone else's problem!