[4.6.x][backport of PR #6337] Make 'S' and 'F' aliases to 's' and 'f' respectively

[webknjaz]

This is a backport of #6337 (by @nicoddemus) with an extra change
note on top of it. It fixes #7310 and supersedes closes #7311 (as an
alternative to a smaller patch as suggested by @RonnyPfannschmidt).

• Include documentation when adding new features.
• Include new tests or update existing tests when applicable.
• Allow maintainers to push and squash when merging my commits. Please uncheck this if you prefer to squash the commits yourself.

Unless your change is trivial or a small documentation fix (e.g., a typo or reword of a small section) please:

• Create a new changelog file in the changelog folder, with a name like <ISSUE NUMBER>.<TYPE>.rst. See changelog/README.rst for details.

  Write sentences in the past or present tense, examples:

  • Improved verbose diff output with sequences.
  • Terminal summary statistics now use multiple colors.

  Also make sure to end the sentence with a ..

• Add yourself to AUTHORS in alphabetical order.

[webknjaz]

Alternative PR: #7311.

[webknjaz]

N.B. Because there was a conflict during cherry-pick, I had to also absorb a small change related to the error outcome that is present on master but not in 4.6.x.

[webknjaz]

This was a part of backport

[webknjaz]

This is new

[webknjaz]

This got absorbed from the master but wasn't a part of the original PR.

[asottile]

fwiw, we have a procedure for backporting patches: https://github.com/pytest-dev/pytest/blob/master/CONTRIBUTING.rst#backporting-bug-fixes-for-the-next-patch-release

[webknjaz]

@asottile oh, I didn't know. What do you want me to do exactly? Should I redo it using -x? I just targeted the commits from the branch that's in the PR.

[nicoddemus]

Hi @webknjaz,

Our procedure is to use:

git co -b backport-6337 upstream/4.6.x
git cherry-pick -m1 ecd1e43

I just did that and got some conflicts in terminal.py, which I suppose is the same one you got. With this procedure we get a nice clean commit with all the changes related to that.

Could you try that and see if it works for you?

[webknjaz]

Also, do I have to follow that branch convention? It doesn't seem important for forks.

[webknjaz]

Ah, I didn't realize that cherry-picking merge commits already does the squash. FWIW I've just force-pushed that as suggested.

[nicoddemus]

Thanks, we appreciate it!

[nicoddemus]

Also, do I have to follow that branch convention? It doesn't seem important for forks.

No you are right, it was just a matter of suggesting something given we have a guide. 😁

[RonnyPfannschmidt]

@webknjaz cherry picking a merge commit will choose the diff to the given parent

[webknjaz]

@RonnyPfannschmidt yeah, I figured. For some I just thought that it'd cherry-pick series of commits from the incoming branch.