GeezerVison

v1.3.0: See your pushes

v1.2.0: Hands off

Maintenance release — CI and release-automation cleanup only. The `br…

…anch`, `pull`, `push`, `merge`, and `stash` commands are unchanged from v1.1.0, so there's nothing new to install if you're already on 1.1.0. (Cutting this partly to exercise the new automated release pipeline end-to-end.)

- modernized CI: least-privilege permissions, run-cancellation on rapid pushes, leaner setup
- replaced the Homebrew bump action with a small inline tap-update step

_[2 commits since v1.1.0](v1.1.0...v1.1.1)_

git-friendly now speaks every modern package manager when you `pull`,…

… and `branch` gets a cleaner, more informative listing.

- **Polyglot `pull`**: detects and runs the right installer for the repo — `uv sync` for Python projects, plus modern lockfile support for bun and bundler. No longer runs `npm install` when a non-npm lockfile is present.
- **Redesigned `branch` listing**: reworked to match `git branch -vvv` style, with tidier formatting and recency-based sorting.
- **Multi-branch delete**: `branch -d`/`-D` now accepts multiple branches in one go.

- `pull` fetches all branches, and no longer double-fetches submodules
- `branch` strips the remote prefix from branch names
- modernized the underlying git invocations, with assorted bug fixes along the way
- added CI tests covering `branch`, `stash`, and `merge`

- **git ≥ 2.23** (2019) — uses `git switch`
- **bash ≥ 3.2** (2006) — macOS's stock bash; no bash 4 features required
- **gh ≥ 2.0** (2021) — optional, only for PR-URL detection in `push`

_[11 commits since v1.0.9](v1.0.9...v1.1.0)_

Ignore claudefiles

Release v1.0.8

branch: fix --set-upstream-to syntax (#122)

This wasn't actually working?

Not sure if regression, change in the underlying git syntax (probably not), or something else, but this fixes it

branch: don't show remote branches by default (#109)

In busy repositories showing remote branches by default makes the `branch` command pretty uselsess

If you want to see remote branches too, use `branch -r`

pull: fix redundant submodule recursion (#94)

The "git submodule update --recursive" does not necessarily behave
the same as "git {fetch,pull} --recurse-submodules=yes" -- the latter
seem to actually explicitly go out and fetch every time? I can't quite
figure out what the ideal behavior here is.

Optionally we could just make the pull use recurse-submodules as a default,
but I don't know what kind of side effects that might introduce.

Bonus: use parallel jobs to do this. I learn something new about git
every day!

Some pnpm-related bugfixes (#104)

Co-authored-by: Artem Sapegin <[email protected]>