handle git pull errors

[ionous]

re: #705; today i learned:

by default, bash doesn't exit automatically when a command fails ( that way, it can handle a failed result and do interesting things ). set -e however turns on automatic exit, and its at the top of the ./shift script.... but then it gets disabled when any of the sub_* commands are called ( at the bottom of the script )

we actually need the no-auto-exit behavior for the "waitUntilServiceIsReady" command, and no-auto-exit is the normal bash default -- so instead of turning it on for sub_pull()... instead i added || exit.

because success is zero and error codes are non-zero, a normal shortcircuiting "or" would only evaluate the right hand expression on success -- but apparently bash has special handling of exit codes ( or maybe all numbers? ) that reverses the expected behavior. 🎉

[ this is somewhat hard to test because you need to create a pull conflict. one way is to explicitly checkout some earlier commit, then manually overwrite your local shift script with the one from this pr, then run "./shift pull" -- it should see the detached head status and punt without launching docker. ]

[ionous]

in this pr, i also removed the "is macOS" use docker compose (with a space) logic. there is no special branching needed. docker-compose (with a dash) works fine on macos

the dash and space versions are different applications. the space version is written in go, the dash version is written in python. go is the current version, python is deprecated. production uses the dash version, and the space version doesn't seem to exist. ( when you type "docker compose --help" on the server you only get general docker help information; you do not get specialized help about the compose command as expected. )

making sure macos and production are actually using the same compose code seems good. so "docker-compose" feels right for all platforms until production can upgrade.

production:

Docker version 24.0.5, build 24.0.5-0ubuntu1~20.04.1

my local:

Docker version 26.1.1, build 4cf5afa

https://docs.docker.com/compose/intro/history/

not sure when, or if we should update the docker environment on production. 24.0.5 is about a year out of date https://docs.docker.com/engine/release-notes/24.0/#2405 -- 2023-07-24

maybe a good separate ticket

[carrythebanner]

Filed Docker update on prod as #772.

[carrythebanner]

We originally did this docker compose vs docker-compose dance to work around some other failures, but that was in 2021/2022 and Docker v20.10 — see commit notes here:
32d9bd2
7ab6a19

As long as this runs in Docker v24 or later on Ubuntu (production) and macOS (both Apple Silicon and Intel), we're all good.

[carrythebanner]

Theoretically it might also run on Windows, but we haven't actively developed/tested that. If it fails on Windows it could be for other reasons and wouldn't be a blocker.

[ionous]

re: production, because it's 'linux' it currently uses the "docker-compose"; so it won't see any change.
re: windows, because this a bash script, it will only run under "linux on windows" anyway, which it sees as 'linux' so it won't see any change. ( someday: i'd love to convert this to a npm script, so that linux on windows isn't needed. )

all that said, it's definitely bad practice to do two things at once. i was just being lazy. i'll make a separate pr for this, and pull ( oh, no puns ) this out.

[ionous]

i've closed this, and will reopen one with a fix.
i tried restoring the lines, but git did strange things with the indentation
( the bash file is unfortunately a mix of tabs and spaces )