This will be useful for learning vanilla Git commands and/or syntax. If I ever have to learn a restricted Git configuration, or if I have to help someone troubleshoot Git without my aliases, this will be useful.

Currently the script repo has to be checked out manually into the correct location, then the installer has to be run.

There should be a pipe-curl-to-shell type command to automatically checkout the repo in the right location, and then run the installer.

Lots of thought should be given to how to do this safely (see https://0x46.net/thoughts/2019/04/27/piping-curl-to-shell/) and numerous other articles. At minimum, we want to guarantee that the script arrived in its entirety and that the user can view it directly in the terminal to screen for malicious bootstrapper content. There's still the matter of malicious contents of the repo, but that's a job that you do when you have some spare time anyway.

The installer should check that the currently checked out repo commit is cryptographically signed with a relevant key.

We do not want to assume that a successful transfer == full integrity. The remote server isn't guaranteed to soft-fail without causing an error exit status on curl. Any proxies for the traffic may also MITM even HTTPS contents, and those can fail too. It might be a good idea to attach a SHA256 or a GPG key fetch in the curl command to combat that. Or perhaps a CRC check might suffice to keep the checksum short. The threat model for this installer doesn't include a successful MITM with malicious intent, since this script will be run on computers that are assumed to be free of compromised or malicious HTTPS CA certificates, so at least the HTTPS connection would guard against that.

The pitfall of this is that, unless a GPG signature is used, the checksum embedded in the command will change every time the installer is changed. This may be a smaller pain from release management POV if the initial installer itself rarely changes.

cksum may be used for this. It seems to be standard-ish across Linux distros (maybe even in POSIX or some base standard?) and gives script length as well to help with connection dropout issues.

Potential idea: write a blog article about this, and the thought process.

Edit: It might be sufficient to place the installer code inside a function (see the end of https://www.arp242.net/curl-to-sh.html), and rely on the assumption that bash will not execute it if the entire function + the entire function invocation command is not transferred across. This would get rid of any noise created by an embedded checksum and make releasing easier. GPG keys should still be verified though.

This is possible with a shell-level override of the Git command like in https://stackoverflow.com/questions/57700953/how-can-i-disable-git-checkout-in-git-2-23. The original command will remain accessible as shell command git-, so it can be still invoked just as fine. There should be a guest mode to temporarily switch Git into a "standard configuration" mode, then back to the enhanced/extended mode.

If it's not selected, just don't write it to the machine-specific config file.

Another alias can be made to create branch without CD-ing. Or have autobr to smartly create a branch.

This is necessary for some GUI tools. For example, IntelliJ's GitLab integration plugin can't detect which upstream branch the current local branch corresponds to, unless this is set up correctly using the Git command line (even when the branch was originally created locally and pushed to the server). This prevents it from being able to open the current file in browser.

Base this on whatever the new Git for Windows installer is doing, and based on recent online guides and SO answers.

E. g. the Windows-specific speed tweaks can be in a module of their own, since grouping them together in the config file is very awkward because some tweak lines belong in a different section of the configuration.

They are currently a mess. Best to re-do them from scratch with a single command that has multiple modes toggled using CLI switches. Make the naming more consistent too.

Some Git commands have likely become deprecated, or replaced with clearer new commands that I can take advantage of by rewriting definitions. This is the ticket for tracking the replacement/rewriting work.

The flaws of the current gitconfig-based approach are becoming more evident. It's time to replace the entry point for the aliases with a shell script. Benefits will include more detailed feedback (i. e. print what a command just did), cleaner definitions for commands that include more than one pipeline stage, more powerful abilities to override Git built-in commands, easier integration with environment variables and resources/data outside the script.

Potential question: should the installer script and the main script be one and the same?