Don't unconditionally add proactiveAuth=basic to Git's config during clone, but only if cloning happens after authentication.
This saves unauthenticated users funny password prompts. On the other hand, this makes a server setting persistent which could be changed on the server.
URL =~ /api/ (or so) => 401, followed by Basic Auth URL !=~ /api/ (or so) => Redirect or free access, depending on resource
Currently all resources, including API, are accessible by either basic auth or a Cookie, but basic auth needs to be present in the first request, which throws off some clients (notably Git without proactiveAuth=basic).
Currently, the primary discriminating criterion on how to handle a set of remote repositories is whether or not JANWARE_USER is defined. The canonical way to do that is PROJECTS_DIR_REMOTE_BASE, though, so go from that definition.
PROJECTS_DIR_REMOTE_USER_SUBPATH is a janware.com specialty somewhat. Having subpaths is a Forgejo feature request on Codeberg, though, so it might also be here to stay.
curl exits with 0 success status, even if the server returns HTTP 401. Passing -f fixes that and has curl error out with exit code 22. It doesn't show which error, though.
Pass -c http.proactiveAuth=basic to the initial "git clone jw-build" invocation. This is necessary while jw-build is still behind authentication. The restriction will likely be lifted (for jw-build), but for testing now it's fine, and it doesn't do any harm, either. With the way janware.com currently operates, it will also necessary for push over HTTP, so make it persistent in jw-build's configuration.
Linking the projects-dir Makefile fails if make pkg-rebuild has been run on jw-build, because it leaves another projects-dir-minimal.mk below the dist directory. Fix that.
The usage comments heading projects-dir-minimal.mk and projects-dir.mk state that for cloning all repositories, JANWARE_USER needs to be defined. That restriction is now gone, so reflect that in the comment.
Add the variable PROJECTS_DIR_REMOTE_BASE, defaulting to ssh://git.janware.com/srv/git if REMOTE_USER is defined, and to https://janware.com/code in case it isn't.
Replace git-srv-admin.sh list-personal-projects by the more universal "jw-projects.py list-repos" for enumerating repo names. This is a step towards supporting Git servers other than janware.com.
Add support for --create-user-repos to pgit.sh. It controls whether or not personal remote repositories on janware.com are created when cloning from another user.
Add the command list-repos to jw-projects.py. It is meant to do the same thing as "git-srv-adm.sh list-personal-projects", i.e. enumerate remote Git repositories, but also support additional servers and protocols. As of this commit, support for https://github.com and for forgejo installations over HTTPS is implemented.
SSHClient(hostname) is an abstract class for SSH / SCP operations. It comes with two implementations, SSHClientInternal an SSHClientCmd. The former needs paramiko installed, which might be a reason to fail on unprepared systems, the latter is slower and more limited.
run_from_cmd_module() is a helper function used to allow command selection alongside the legacy and now obsolete method. Unrolling it is a step towards adding proper argparse subparsers, so do that.
jw-pkg is related to, but strictly speaking not indispensible for building and packaging software. So, in the attempt have a minimal jw-build, move jw-pkg to jw-base, and fix all packages that use it.
Make list-files target ignore errors. This catches errors from git ls-files | xargs realpath if git ls-files lists dead symbolic links, as in my-project/blah/dev/fd -> ./proc/self/fd.
Implemented by passing -q (quiet) to realpath, not sure what else this suppresses.
