Hi Ken
>> ... those commands have to have a pattern - not custom tailored for each plug-in.
>
> It's not git commands that were the issue is was the way the provider of the plugin offered the plugin
That is exactly the problem! Taking an example:
Moodle Core, a major upgrade
$ git branch --track MOODLE_PQR_STABLE origin/MOODLE_XYZ_STABLE
$ git checkout MOODLE_XYZ_STABLE
$ git pull
Now take the plug-ins in https://moodle.org/mod/forum/discuss.php?d=454264#p1825189
$ /path/to/first/plugin
$ [What should I enter?]
$ /path/to/second/plugin
$ [What should I enter?]
You see? There no way of knowing this beforehand, other than reading the documentation of each and/or going to each plug-in directory and some experimenting with Git commands.
My proposal is to whether Moodle HQ ask the developers of the additional plug-ins to follow a common naming convention for their Git branches, which make the answers to those [What should I enter?] questions trivial.
HQ has managed to force everybody to Git, then to GitHub, no GitLab, for example. Then why not this?
> if all plugins had been installed with git to begin with ...
Yes, I am talking of additional plug-ins that have been pulled using Git.
> cd /path/to/first/plugin
> git pull
> cd /path/to/second/plugin
> git pull
Yes, that is what I expect, if I stay within the same major release (second digit). What about a release upgrade, P.Q.R > X.Y.latest where X.Y is a higher release than the P.Q and allows direct jump from P.Q?