PGIT_SH_PROJECTS currently only sets the projects to operate on for the get command. Extend this to all commands. And replace the environment variable by a command-line option, likely after this script has been ported to Python.
"clone" in the Git sense means to copy a remote project over from scratch. pgit.sh clone has come from that, but has since evolved into something different, a mixture of clone, pull and fetch, so find a different name. "get" seems generic enough and doesn't clash with a Git meaning. Adapt variable names accordingly across the project.
Continue to name variables in pgit.sh somewhat more consistently, notably turn somevar into some_var. Plus some additional cleanup. Still not a beauty.
If "current-branch" is specified within --refspec, either as from-ref or as to-ref, expand that to the branch the working directory has currently checked out.
This commit allows pgit.sh to target not only multiple projects below a projects-directory, but also one single project. If invoked from the toplevel directory of a project, it uses that as the only project it should deal with. This is meant to facilitate running the same VCS abstraction logic for one project as for many projects. The project or projects to deal with should probably be specified on the command line, but changing the auto-detection mechanism buys us what we want for now with low hassle.
Some variable names are too short for global scope ($p, $pdir, $pdirs), among others. For those mentioned: Make them longer and more descriptive.
Also add a variable project_name, which denotes what a project is in a remote repository, and which is currently but not necessarily always the same as the project directory.
Calling make git-pull-xxx from a projects directory stops iterating projects if one has a dirty workspace. Calling --autostash fixes that.
With this in place, a failed rebase leaves the local changes behind stashed. So, after manually fixing the rebase, the stash needs to be manually reapplied. The commands that led up to the failure are logged right before, so I have hope that this is learnable, and not too much of a footgun.
Before merging the remote branch, do a rebase. This may fail and prompt conflict resolution, but that seems the canonical outcome for the common use case "interactive make git pull-xxx" with master out-of-sync.
Reorganize the Python module structure. Placing the command classes under jw.cmds.projects instead of jw.build.cmds will allow to add a nested command structure, with the current commands, being mostly related to building software, found below a "projects" toplevel command.
Other conceivable commands could be "package" for packaging, or "distro" for commands wrapping the distribution's package manager.
"git fetch $remote $fromref:$toref" fails if the $fromref is behind $toref.
Unrolling the syntax into "git fetch" followed by "git merge --ff-only $remote/$fromref $toref" is accepted, though, and saves some otherwise necessary case distinction code around it.
jw-build doesn't stop at building software, packaging it afterwards is also a core feature, so this commit gives the package a better name.
The commit replaces strings s/jw-build/jw-pkg/ in text files and file names. Fallout to the functionality is fixed, variable names are left as they are, though. To be adjusted by later commits.
--login is not understood by pgit.sh push. Solve that by allowing all commands a --login option. This addresses our use case, but isn't ideal of course. Will be finally fixed by moving pgit.sh's functionality into Python code.
pgit.sh clone --login <username> fails to insert said username into a remotes url while adding it: Of ssh://<username>@git.janware.com/srv/git, only ssh://@git.janware.com/srv/git makes it into the config. Fix that.
In the attempt to move away from communicating options via environment variables from one part of jw-build software to another, replace PGIT_CLONE_FROM_USER with the clearer --refspec option. Which is also more versatile.
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).
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.
This adds support for the variable OFFLINE_PROJECTS in projects-dir.mk and the PGIT_IGNORE environment variable. Both go hand in hand and do what their names insinuate. OFFLINE_PROJECTS is initialized from EXCLUDE_FROM_BUILD, which in turn is initialized from exclude.txt and friends.
PGIT_CLONE_CLONE_FROM_USER now supports optional suffixes of the form [:src-ref[:dst-ref]]. If present, src-ref specifies the remote branch pgit.sh tries to fetch, and dst-ref the local branch it tries to fetch into. src-ref defaults to "master" (as it was before) and dst-ref to nothing, i.e. no head-update of any local branch.
Sadly, a commit returns 1 if there's nothing to commit, which makes pgit.sh error out of the project loop, which is run with set -e. This option disables -e.
OTOH, pgit.sh commit could check for a diff and only run git commit if there is a diff.
The diff source and destination in diff used to be a/path/to/file.txt and b/path/to/file.txt which differed from cvs diff -u. Changed that, now make diff in the toplevel directory creates usable patches for all sources.
