[CM H1] fixed mount plugin tutorial, as mentioned on tuwel

[philippoppel]

Tuwel issue: https://tuwel.tuwien.ac.at/mod/forum/discuss.php?d=243029#p598964

closes #3722 & also added sudo to the first command, which is necessary anyway

Basics

These points need to be fulfilled for every PR:

• Short descriptions of your changes are in the release notes
  (added as entry in doc/news/_preparation_next_release.md which
  contains _(my name)_)
  Please always add something to the release notes.
• Details of what you changed are in commit messages
  (first line should have module: short statement syntax)
• References to issues, e.g. close #X, are in the commit messages.
• The buildservers are happy. If not, fix in this order:
  • add a line in doc/news/_preparation_next_release.md
  • reformat the code with scripts/dev/reformat-all
  • make all unit tests pass
  • fix all memleaks
• The PR is rebased with current master.

If you have any troubles fulfilling these criteria, please write
about the trouble as comment in the PR. We will help you.
But we cannot accept PRs that do not fulfill the basics.

Checklist

Check relevant points but please do not remove entries.
For docu fixes, spell checking, and similar none of these points below
need to be checked.

• I added unit tests for my code
• I fully described what my PR does in the documentation
  (not in the PR description)
• I fixed all affected documentation
• I added code comments, logging, and assertions as appropriate (see Coding Guidelines)
• I updated all meta data (e.g. README.md of plugins and METADATA.ini)
• I mentioned every code not directly written by me in THIRD-PARTY-LICENSES

Review

Reviewers will usually check the following:

• Documentation is introductory, concise, good to read and describes everything what the PR does
• Examples are well chosen and understandable
• Code is conforming to our Coding Guidelines
• APIs are conforming to our Design Guidelines
• Code is consistent to our Design Decisions

Labels

If you are already Elektra developer:

• Add the "work in progress" label if you do not want the PR to be reviewed yet.
• Add the "ready to merge" label if the basics are fulfilled and you also
  say that everything is ready to be merged.

[kodebach]

LGTM

[mpranj]

Thank you so much for the contribution. Please fix the merge conflict by rebasing from master.

@kodebach please merge if this fully resolves #3722.

[mpranj]

Any news here?

This PR needs a rebase and has open review points.

[philippoppel]

Hey, I rebased from master and added a better description, is it fine now?

[mpranj]

Thank you! Your PR looks good, but there are still merge conflicts.

Are you sure you rebased from current upstream/master and not an outdated master branch? See the docs for hints how to work with and sync forks.

[mpranj]

Seems like something went wrong. There is a merge commit which should not be there when rebasing and the PR contains about 390 unrelated commits.

I created #3805, which is a rebased copy of this PR, as an example how it should look.

[philippoppel]

thank you for fixing this, sorry for the hassle

when I tried rebasing to upstream/master it did work, but when I tried to push it, my IDE wanted me to merge otherwise my push was rejected. As far as I understood it, I should have reverted the merges I did before and make like a "clean" rebase, correct?

[mpranj]

Thank you for the PR and the documentation fixes! It was merged via #3805.

I should have reverted the merges I did before and make like a "clean" rebase, correct?

Afair I simply copied your branch and then rebased from upstream/master again and this already removed the merge commit. Then I fixed some merge errors that were done before (duplicate news entries).
If nothing else works another method is: create a new branch starting from upstream/master and then git cherry-pick all relevant commits. This is usually the last resort though.