Add instructions for basic use of msync when needing to make updates

[ehelms]

No description provided.

[wbclark]

Suggested change

	This will clone all modules into `modules/` and apply any pending updates. Changes can then be inspected and Pull Request's
	This will clone all modules into `modules/` and apply any pending updates. Changes can then be inspected and Pull Requests

[wbclark]

Should we also provide instructions for using msync update --pr ? Is that part of the typical workflow with this tool?

[ekohl]

Should we also provide instructions for using msync update --pr ? Is that part of the typical workflow with this tool?

I personally never used it. Mostly because I got used to doing it manual before modulesync could do that. Only with ce29c2c (just merged) we updated to a version that supports the option.

[ehelms]

I never used it because it always did things from the main repository and not from the my fork, which I prefer if I am the one opening PRs to make it cleaner and prevent branch bloat.

[ekohl]

I never used it because it always did things from the main repository and not from the my fork, which I prefer if I am the one opening PRs to make it cleaner and prevent branch bloat.

I didn't mention it, but that is indeed also something I thought about. I also like to review any changes before I submit the PR. Then I create PRs in a shell loop using hub.

Does it also make sense to mention --offline and -f flags?

[ehelms]

Does it also make sense to mention --offline and -f flags?

If you can tell me the workflow and use case I will include it. My one use of --offline led to ending up with a confused state of my modules.

[ekohl]

What I often do is use --noop to set up the branch structure. I notice a mistake, change the templates, run it with --offline to avoid all git operations. If I just want to change a single module, I use -f pulp for example (note pulp also matches pulpcore).