git-epic 0.1.0__tar.gz

git_epic-0.1.0/MANIFEST.in

@@ -0,0 +1,2 @@
+include README.md pyproject.toml publish.sh
+recursive-include tests *.py

git_epic-0.1.0/PKG-INFO

@@ -0,0 +1,205 @@
+Metadata-Version: 2.4
+Name: git-epic
+Version: 0.1.0
+Summary: Epic-based Git workflows and GitLab merge requests
+Author: Wonderteam
+Project-URL: Repository, https://gitlab.wonderbeauties.com/wonderteam/git-epic
+Project-URL: Issues, https://gitlab.wonderbeauties.com/wonderteam/git-epic/-/issues
+Keywords: git,cli,gitlab,epic,workflow
+Classifier: Development Status :: 3 - Alpha
+Classifier: Environment :: Console
+Classifier: Intended Audience :: Developers
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3 :: Only
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
+Classifier: Topic :: Software Development :: Version Control :: Git
+Requires-Python: >=3.11
+Description-Content-Type: text/markdown
+Provides-Extra: dev
+Requires-Dist: build<2,>=1.2; extra == "dev"
+Requires-Dist: ruff<1,>=0.11; extra == "dev"
+Requires-Dist: twine<7,>=6; extra == "dev"
+
+# git-epic
+
+A Python CLI for our epic-based Git workflow, with no runtime Python dependencies.
+Git discovers the `git-epic`
+executable automatically, so commands use `git epic …`.
+
+## Install
+
+Requires Python 3.11+, Git 2.31+, and [glab](https://gitlab.com/gitlab-org/cli).
+Authenticate once with your GitLab host:
+
+```sh
+glab auth login --hostname gitlab.wonderbeauties.com
+```
+
+After the first PyPI release, install with [pipx](https://pipx.pypa.io/):
+
+```sh
+pipx install git-epic
+pipx ensurepath
+git epic -h
+```
+
+For local development before publication:
+
+```sh
+pipx install .
+pipx ensurepath
+git epic -h
+```
+
+If `ensurepath` changes your PATH, open a new terminal. Upgrade with
+`pipx upgrade git-epic`. The package is not yet published; `pipx install .` works
+from a local checkout today.
+
+## Commands
+
+Use `git epic -h` for CLI help. Git reserves `git epic --help` for a system manual
+page; this MVP does not install one. Direct invocation also supports
+`git-epic --help`.
+
+| Command | Behavior |
+| --- | --- |
+| `git epic init` | Write shared `.git-epic.json`; defaults to `production`, `origin`, and GitLab. |
+| `git epic start <name>` | Fetch production; create and switch to local `epic/<name>`. |
+| `git epic task start <name>` | From an epic, fetch and fast-forward remote epic changes if possible; create `task/<epic>/<name>`. |
+| `git epic task submit` | Push committed task changes; create or return its parent epic MR. Publish the local parent epic if it is not yet on the remote. |
+| `git epic sync` | From an epic, fetch and merge production. Push the result yourself or with `release`. |
+| `git epic status` | Fetch; show current task/epic, labelled local/remote epic drift, related open MRs (including task MRs when on an epic), and their latest reported CI status. |
+| `git epic release` | Push committed epic changes; create or return an MR targeting production. **Never merges or deploys.** |
+
+GitLab calls PRs **merge requests (MRs)**. Submission commands also push new commits
+when returning an existing MR; they do not create a duplicate.
+
+Names are single segments: letters, numbers, dots, underscores, and hyphens, starting
+with a letter or number. Git's branch-name restrictions also apply.
+
+For repositories using a different production branch or remote:
+
+```sh
+git epic init --production main --remote origin
+git add .git-epic.json
+git commit -m "Configure git-epic"
+git push
+```
+
+Commit this file on production before creating epics so all branches and teammates
+inherit it. It contains no credentials. Existing configuration is never overwritten;
+edit the file to change settings. An initial production commit must already exist on
+the remote; `init` does not bootstrap an empty application repository.
+
+## Typical workflow
+
+```sh
+git epic start checkout
+git epic task start payment
+# Implement and commit your task.
+git epic task submit
+# Review, CI, and merge the task MR in GitLab.
+git switch epic/checkout
+# Bring merged tasks into the local epic.
+git fetch origin
+git merge --ff-only origin/epic/checkout
+git epic sync
+git push origin epic/checkout
+# Deploy OTF and obtain QA approval through the existing team process.
+git epic release
+# Review, required CI, and merge in GitLab; CI/CD deploys production.
+```
+
+OTF deployment and QA approval are external to this CLI. Approval belongs to an
+exact commit/build. If the candidate or production changes, update and revalidate
+before merging. `release` refuses an epic that is behind current production, but
+the hosting platform/CI must also enforce release checks at merge time. The CLI
+does not record or verify QA approval.
+
+## Git behavior
+
+- Branch and submission operations require a clean working tree and no unfinished
+  merge/rebase/cherry-pick/revert. `status` allows uncommitted changes.
+- Fetch updates remote-tracking refs. No command force-pushes, resets, deletes a
+  branch, merges an MR, or deploys.
+- `start` creates a local epic. Submission publishes branches with ordinary pushes;
+  non-fast-forward pushes are rejected rather than overwriting teammates' work.
+- `task start` stops if local and remote epic histories have diverged. Reconcile
+  the epic using Git before retrying. `release` similarly requires your local epic
+  to include remote epic work before a push can succeed.
+- If `sync` conflicts, resolve and commit, or use `git merge --abort`.
+- An MR/API failure after a push leaves the branch published; retry the command.
+- GitLab authentication is managed by `glab`, and Git authentication by Git.
+
+## Development and release
+
+```sh
+python3 -m venv .venv
+source .venv/bin/activate
+python -m pip install -e '.[dev]'
+ruff check .
+ruff format --check .
+python -m unittest discover -s tests -v
+python -m build
+python -m twine check --strict dist/*.whl dist/*.tar.gz
+```
+
+Tests create temporary local Git repositories and a fake `glab`; they never create
+real MRs or touch production. GitLab API behavior is delegated to the installed
+`glab`. CI checks Python 3.11 and 3.14, builds a wheel and source distribution,
+validates metadata with Twine, and smoke-tests the installed wheel via Git.
+
+## Publish to PyPI
+
+### Local publication helper
+
+From a clean, committed checkout with a configured Git upstream, run:
+
+```sh
+./publish.sh
+```
+
+The helper uses `uv` to prompt for a PEP 440 version (press Enter to keep the
+current version for the first release), update the version and README release-tag
+examples, run tests, clean and build distributions, validate with Twine, upload
+to PyPI, and commit/push the release changes. Set `PYPI_API_TOKEN` or
+`TWINE_PASSWORD` in your shell; otherwise Twine prompts for authentication.
+It does not create a release tag or trigger the CI publication job.
+
+### GitLab CI publication
+
+The distribution name is **`git-epic`**, import package is **`git_epic`**, and CLI
+entry point is **`git-epic`**. Version is defined once in
+`src/git_epic/__init__.py`.
+
+1. Create a PyPI account and an API token. For the first release, a token with
+   account scope is needed; after creating the project, use a project-scoped token.
+2. In GitLab CI/CD variables, add **`PYPI_API_TOKEN`** as a masked, protected
+   variable. Protect the release tag pattern (`v*`) so tagged jobs can access it.
+3. Update the version, then push a matching tag, for example `v0.1.0`.
+4. After verification and build jobs pass, manually run **`publish:pypi`**.
+
+The job uploads only the validated wheel and source distribution from the build
+job. A release tag must match the package version. PyPI does not allow reusing
+an uploaded version: use a new version for subsequent releases.
+
+An optional **`publish:testpypi`** job uses **`TESTPYPI_API_TOKEN`** and the separate
+TestPyPI registry. TestPyPI accounts and tokens are independent of PyPI. A test
+installation uses `pipx install --index-url https://test.pypi.org/simple/ git-epic`.
+
+For a manual upload of locally built, validated distributions:
+
+```sh
+export TWINE_USERNAME=__token__
+# Set TWINE_PASSWORD to your PyPI API token in your shell.
+python -m twine upload --non-interactive dist/*.whl dist/*.tar.gz
+```
+
+Credentials are supplied by the shell or CI, never stored in project files. PyPI
+Trusted Publishing currently supports GitLab.com, not this self-managed GitLab
+host, so the release jobs use API tokens. Package-name availability is determined
+by PyPI at upload time. A public PyPI release includes the source code even when
+the GitLab repository is private.

git_epic-0.1.0/README.md

@@ -0,0 +1,180 @@
+# git-epic
+
+A Python CLI for our epic-based Git workflow, with no runtime Python dependencies.
+Git discovers the `git-epic`
+executable automatically, so commands use `git epic …`.
+
+## Install
+
+Requires Python 3.11+, Git 2.31+, and [glab](https://gitlab.com/gitlab-org/cli).
+Authenticate once with your GitLab host:
+
+```sh
+glab auth login --hostname gitlab.wonderbeauties.com
+```
+
+After the first PyPI release, install with [pipx](https://pipx.pypa.io/):
+
+```sh
+pipx install git-epic
+pipx ensurepath
+git epic -h
+```
+
+For local development before publication:
+
+```sh
+pipx install .
+pipx ensurepath
+git epic -h
+```
+
+If `ensurepath` changes your PATH, open a new terminal. Upgrade with
+`pipx upgrade git-epic`. The package is not yet published; `pipx install .` works
+from a local checkout today.
+
+## Commands
+
+Use `git epic -h` for CLI help. Git reserves `git epic --help` for a system manual
+page; this MVP does not install one. Direct invocation also supports
+`git-epic --help`.
+
+| Command | Behavior |
+| --- | --- |
+| `git epic init` | Write shared `.git-epic.json`; defaults to `production`, `origin`, and GitLab. |
+| `git epic start <name>` | Fetch production; create and switch to local `epic/<name>`. |
+| `git epic task start <name>` | From an epic, fetch and fast-forward remote epic changes if possible; create `task/<epic>/<name>`. |
+| `git epic task submit` | Push committed task changes; create or return its parent epic MR. Publish the local parent epic if it is not yet on the remote. |
+| `git epic sync` | From an epic, fetch and merge production. Push the result yourself or with `release`. |
+| `git epic status` | Fetch; show current task/epic, labelled local/remote epic drift, related open MRs (including task MRs when on an epic), and their latest reported CI status. |
+| `git epic release` | Push committed epic changes; create or return an MR targeting production. **Never merges or deploys.** |
+
+GitLab calls PRs **merge requests (MRs)**. Submission commands also push new commits
+when returning an existing MR; they do not create a duplicate.
+
+Names are single segments: letters, numbers, dots, underscores, and hyphens, starting
+with a letter or number. Git's branch-name restrictions also apply.
+
+For repositories using a different production branch or remote:
+
+```sh
+git epic init --production main --remote origin
+git add .git-epic.json
+git commit -m "Configure git-epic"
+git push
+```
+
+Commit this file on production before creating epics so all branches and teammates
+inherit it. It contains no credentials. Existing configuration is never overwritten;
+edit the file to change settings. An initial production commit must already exist on
+the remote; `init` does not bootstrap an empty application repository.
+
+## Typical workflow
+
+```sh
+git epic start checkout
+git epic task start payment
+# Implement and commit your task.
+git epic task submit
+# Review, CI, and merge the task MR in GitLab.
+git switch epic/checkout
+# Bring merged tasks into the local epic.
+git fetch origin
+git merge --ff-only origin/epic/checkout
+git epic sync
+git push origin epic/checkout
+# Deploy OTF and obtain QA approval through the existing team process.
+git epic release
+# Review, required CI, and merge in GitLab; CI/CD deploys production.
+```
+
+OTF deployment and QA approval are external to this CLI. Approval belongs to an
+exact commit/build. If the candidate or production changes, update and revalidate
+before merging. `release` refuses an epic that is behind current production, but
+the hosting platform/CI must also enforce release checks at merge time. The CLI
+does not record or verify QA approval.
+
+## Git behavior
+
+- Branch and submission operations require a clean working tree and no unfinished
+  merge/rebase/cherry-pick/revert. `status` allows uncommitted changes.
+- Fetch updates remote-tracking refs. No command force-pushes, resets, deletes a
+  branch, merges an MR, or deploys.
+- `start` creates a local epic. Submission publishes branches with ordinary pushes;
+  non-fast-forward pushes are rejected rather than overwriting teammates' work.
+- `task start` stops if local and remote epic histories have diverged. Reconcile
+  the epic using Git before retrying. `release` similarly requires your local epic
+  to include remote epic work before a push can succeed.
+- If `sync` conflicts, resolve and commit, or use `git merge --abort`.
+- An MR/API failure after a push leaves the branch published; retry the command.
+- GitLab authentication is managed by `glab`, and Git authentication by Git.
+
+## Development and release
+
+```sh
+python3 -m venv .venv
+source .venv/bin/activate
+python -m pip install -e '.[dev]'
+ruff check .
+ruff format --check .
+python -m unittest discover -s tests -v
+python -m build
+python -m twine check --strict dist/*.whl dist/*.tar.gz
+```
+
+Tests create temporary local Git repositories and a fake `glab`; they never create
+real MRs or touch production. GitLab API behavior is delegated to the installed
+`glab`. CI checks Python 3.11 and 3.14, builds a wheel and source distribution,
+validates metadata with Twine, and smoke-tests the installed wheel via Git.
+
+## Publish to PyPI
+
+### Local publication helper
+
+From a clean, committed checkout with a configured Git upstream, run:
+
+```sh
+./publish.sh
+```
+
+The helper uses `uv` to prompt for a PEP 440 version (press Enter to keep the
+current version for the first release), update the version and README release-tag
+examples, run tests, clean and build distributions, validate with Twine, upload
+to PyPI, and commit/push the release changes. Set `PYPI_API_TOKEN` or
+`TWINE_PASSWORD` in your shell; otherwise Twine prompts for authentication.
+It does not create a release tag or trigger the CI publication job.
+
+### GitLab CI publication
+
+The distribution name is **`git-epic`**, import package is **`git_epic`**, and CLI
+entry point is **`git-epic`**. Version is defined once in
+`src/git_epic/__init__.py`.
+
+1. Create a PyPI account and an API token. For the first release, a token with
+   account scope is needed; after creating the project, use a project-scoped token.
+2. In GitLab CI/CD variables, add **`PYPI_API_TOKEN`** as a masked, protected
+   variable. Protect the release tag pattern (`v*`) so tagged jobs can access it.
+3. Update the version, then push a matching tag, for example `v0.1.0`.
+4. After verification and build jobs pass, manually run **`publish:pypi`**.
+
+The job uploads only the validated wheel and source distribution from the build
+job. A release tag must match the package version. PyPI does not allow reusing
+an uploaded version: use a new version for subsequent releases.
+
+An optional **`publish:testpypi`** job uses **`TESTPYPI_API_TOKEN`** and the separate
+TestPyPI registry. TestPyPI accounts and tokens are independent of PyPI. A test
+installation uses `pipx install --index-url https://test.pypi.org/simple/ git-epic`.
+
+For a manual upload of locally built, validated distributions:
+
+```sh
+export TWINE_USERNAME=__token__
+# Set TWINE_PASSWORD to your PyPI API token in your shell.
+python -m twine upload --non-interactive dist/*.whl dist/*.tar.gz
+```
+
+Credentials are supplied by the shell or CI, never stored in project files. PyPI
+Trusted Publishing currently supports GitLab.com, not this self-managed GitLab
+host, so the release jobs use API tokens. Package-name availability is determined
+by PyPI at upload time. A public PyPI release includes the source code even when
+the GitLab repository is private.

git_epic-0.1.0/publish.sh

@@ -0,0 +1,129 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+cd -- "$(dirname -- "${BASH_SOURCE[0]}")"
+
+printf '\nGit Epic — PyPI Publication Helper\n----------------------------------\n'
+
+if ! command -v uv >/dev/null 2>&1; then
+    printf 'Error: Install uv before running this script.\n' >&2
+    exit 1
+fi
+
+if ! git rev-parse --verify HEAD >/dev/null 2>&1; then
+    printf 'Error: Commit and push the initial project before publishing a release.\n' >&2
+    exit 1
+fi
+
+if [[ -n "$(git status --porcelain --untracked-files=all --ignore-submodules=none)" ]]; then
+    printf 'Error: Commit or stash your changes before publishing.\n' >&2
+    exit 1
+fi
+
+if ! git symbolic-ref --quiet HEAD >/dev/null ||
+   ! git rev-parse --verify '@{upstream}' >/dev/null 2>&1; then
+    printf 'Error: Check out a branch with a configured upstream before publishing.\n' >&2
+    exit 1
+fi
+
+# uv manages the interpreter and build tools without a global pip installation.
+release_python() {
+    uv run --no-project --python 3.11 \
+        --with 'build>=1.2,<2' \
+        --with 'twine>=6,<7' \
+        --with 'packaging>=24' \
+        python "$@"
+}
+
+CURRENT_VERSION=$(release_python - <<'PY'
+import ast
+from pathlib import Path
+
+tree = ast.parse(Path("src/git_epic/__init__.py").read_text(encoding="utf-8"))
+for node in tree.body:
+    if isinstance(node, ast.Assign) and any(
+        isinstance(target, ast.Name) and target.id == "__version__" for target in node.targets
+    ):
+        print(ast.literal_eval(node.value))
+        break
+else:
+    raise SystemExit("Error: Could not find __version__.")
+PY
+)
+
+printf 'Current version: %s\n' "$CURRENT_VERSION"
+read -r -p "Enter release version [$CURRENT_VERSION]: " NEW_VERSION
+NEW_VERSION=${NEW_VERSION:-$CURRENT_VERSION}
+
+NEW_VERSION=$(release_python - "$CURRENT_VERSION" "$NEW_VERSION" <<'PY'
+import sys
+from packaging.version import InvalidVersion, Version
+
+try:
+    current, new = map(Version, sys.argv[1:])
+except InvalidVersion as error:
+    raise SystemExit(f"Error: {error}") from error
+if new < current:
+    raise SystemExit("Error: Release version cannot be older than the current version.")
+if new.local is not None:
+    raise SystemExit("Error: PyPI does not accept local version identifiers.")
+print(new)
+PY
+)
+
+printf 'Updating version to %s...\n' "$NEW_VERSION"
+release_python - "$CURRENT_VERSION" "$NEW_VERSION" <<'PY'
+import re
+import sys
+from pathlib import Path
+
+current, new = sys.argv[1:]
+path = Path("src/git_epic/__init__.py")
+text, count = re.subn(
+    r'^__version__ = "[^"]+"$', f'__version__ = "{new}"',
+    path.read_text(encoding="utf-8"), flags=re.MULTILINE,
+)
+if count != 1:
+    raise SystemExit("Error: Expected exactly one __version__ assignment.")
+path.write_text(text, encoding="utf-8")
+# Update release-tag examples only, leaving unrelated numbers intact.
+readme = Path("README.md")
+readme.write_text(
+    readme.read_text(encoding="utf-8").replace(f"`v{current}`", f"`v{new}`"),
+    encoding="utf-8",
+)
+PY
+
+printf 'Running tests...\n'
+PYTHONPATH="$PWD/src" release_python -m unittest discover -s tests -v
+
+printf 'Cleaning old builds...\n'
+release_python - <<'PY'
+import shutil
+from pathlib import Path
+
+for path in (Path("dist"), Path("build"), Path("src/git_epic.egg-info")):
+    if path.exists():
+        shutil.rmtree(path)
+PY
+
+printf 'Building and validating package...\n'
+release_python -m build --installer uv
+release_python -m twine check --strict dist/*.whl dist/*.tar.gz
+
+printf 'Uploading to PyPI...\n'
+export TWINE_USERNAME="${TWINE_USERNAME:-__token__}"
+if [[ -z "${TWINE_PASSWORD:-}" && -n "${PYPI_API_TOKEN:-}" ]]; then
+    export TWINE_PASSWORD="$PYPI_API_TOKEN"
+fi
+release_python -m twine upload --repository-url https://upload.pypi.org/legacy/ \
+    dist/*.whl dist/*.tar.gz
+
+printf 'Committing and pushing release changes...\n'
+git add -- src/git_epic/__init__.py README.md
+if ! git diff --cached --quiet; then
+    git commit -m "Release v${NEW_VERSION}"
+fi
+git push
+
+printf '\nSuccessfully published and pushed git-epic %s!\n' "$NEW_VERSION"

git_epic-0.1.0/pyproject.toml

@@ -0,0 +1,48 @@
+[build-system]
+requires = ["setuptools>=77"]
+build-backend = "setuptools.build_meta"
+
+[project]
+name = "git-epic"
+dynamic = ["version"]
+description = "Epic-based Git workflows and GitLab merge requests"
+readme = "README.md"
+requires-python = ">=3.11"
+dependencies = []
+authors = [{name = "Wonderteam"}]
+keywords = ["git", "cli", "gitlab", "epic", "workflow"]
+classifiers = [
+  "Development Status :: 3 - Alpha",
+  "Environment :: Console",
+  "Intended Audience :: Developers",
+  "Programming Language :: Python :: 3",
+  "Programming Language :: Python :: 3 :: Only",
+  "Programming Language :: Python :: 3.11",
+  "Programming Language :: Python :: 3.12",
+  "Programming Language :: Python :: 3.13",
+  "Programming Language :: Python :: 3.14",
+  "Topic :: Software Development :: Version Control :: Git",
+]
+
+[project.scripts]
+git-epic = "git_epic.cli:main"
+
+[project.optional-dependencies]
+dev = ["build>=1.2,<2", "ruff>=0.11,<1", "twine>=6,<7"]
+
+[project.urls]
+Repository = "https://gitlab.wonderbeauties.com/wonderteam/git-epic"
+Issues = "https://gitlab.wonderbeauties.com/wonderteam/git-epic/-/issues"
+
+[tool.setuptools.dynamic]
+version = {attr = "git_epic.__version__"}
+
+[tool.setuptools.packages.find]
+where = ["src"]
+
+[tool.ruff]
+target-version = "py311"
+line-length = 100
+
+[tool.ruff.lint]
+select = ["E", "F", "I", "UP", "B"]

git_epic-0.1.0/setup.cfg

@@ -0,0 +1,4 @@
+[egg_info]
+tag_build = 
+tag_date = 0
+

git_epic-0.1.0/src/git_epic/__init__.py

@@ -0,0 +1,3 @@
+"""Epic-based Git workflows."""
+
+__version__ = "0.1.0"

git_epic-0.1.0/src/git_epic/__main__.py

@@ -0,0 +1,3 @@
+from .cli import main
+
+raise SystemExit(main())

git_epic-0.1.0/src/git_epic/cli.py

@@ -0,0 +1,56 @@
+"""Command-line entry point, available as git-epic and git epic."""
+
+import argparse
+import sys
+
+from . import __version__, workflow
+from .process import EpicError
+
+
+def parser() -> argparse.ArgumentParser:
+    root = argparse.ArgumentParser(
+        prog="git epic", description="Epic-based Git workflows and GitLab merge requests"
+    )
+    root.add_argument("--version", "-V", action="version", version=__version__)
+    commands = root.add_subparsers(dest="command", required=True)
+    init = commands.add_parser("init", help="Configure this repository")
+    init.add_argument("--production", default="production", metavar="BRANCH")
+    init.add_argument("--remote", default="origin")
+    start = commands.add_parser("start", help="Create an epic from latest production")
+    start.add_argument("name")
+    task = commands.add_parser("task", help="Work on tasks within an epic")
+    tasks = task.add_subparsers(dest="task_command", required=True)
+    task_start = tasks.add_parser("start", help="Create a task from the current epic")
+    task_start.add_argument("name")
+    tasks.add_parser("submit", help="Push the task and create or return its epic MR")
+    commands.add_parser("sync", help="Merge latest production into the current epic")
+    commands.add_parser("status", help="Show branch context, production drift, MRs, and CI")
+    commands.add_parser(
+        "release",
+        help="Push the epic and create or return its production MR; never merge or deploy",
+    )
+    return root
+
+
+def main(argv: list[str] | None = None) -> int:
+    args = parser().parse_args(argv)
+    try:
+        if args.command == "init":
+            workflow.init(args.production, args.remote)
+        elif args.command == "start":
+            workflow.start(args.name)
+        elif args.command == "task":
+            if args.task_command == "start":
+                workflow.task_start(args.name)
+            else:
+                workflow.task_submit()
+        else:
+            {"sync": workflow.sync, "status": workflow.status, "release": workflow.release}[
+                args.command
+            ]()
+    except (EpicError, OSError) as error:
+        print(f"git-epic: {error}", file=sys.stderr)
+        return 1
+    except KeyboardInterrupt:
+        return 130
+    return 0