If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/aanand/git-up shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 9y ago

• 18 active contributors
• MIT licensed
• ⚠ Stale — last commit 9y ago
• ⚠ Concentrated ownership — top contributor handles 73% of recent commits
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live aanand/git-up repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/aanand/git-up.

What it runs against: a local clone of aanand/git-up — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in aanand/git-up | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 3135 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of aanand/git-up. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/aanand/git-up.git
#   cd git-up
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of aanand/git-up and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "aanand/git-up(\\.git)?\\b" \\
  && ok "origin remote is aanand/git-up" \\
  || miss "origin remote is not aanand/git-up (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "bin/git-up" \\
  && ok "bin/git-up" \\
  || miss "missing critical file: bin/git-up"
test -f "lib/git-up.rb" \\
  && ok "lib/git-up.rb" \\
  || miss "missing critical file: lib/git-up.rb"
test -f "lib/git-up/version.rb" \\
  && ok "lib/git-up/version.rb" \\
  || miss "missing critical file: lib/git-up/version.rb"
test -f "git-up.gemspec" \\
  && ok "git-up.gemspec" \\
  || miss "missing critical file: git-up.gemspec"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 3135 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3105d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/aanand/git-up"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

git-up is a Ruby CLI tool that fetches and rebases all locally-tracked remote branches in one command, solving two problems with git pull: it rebases instead of merging (keeping commit history clean) and updates all remote-tracking branches, not just the current one. It wraps git operations to provide a single git up command that performs multi-branch synchronization with automatic stashing. Single Ruby gem with executable: bin/git-up is the CLI entry point, lib/git-up.rb is the main library file, lib/git-up/ subdirectory contains modular components, and git-up.gemspec defines the gem package. Simple flat structure with man page at man/git-up.1 and Docker support via Dockerfile and docker-compose.yml.

Git workflow enthusiasts and developers who want to keep their repository history linear and ensure all local branches stay synchronized with their remotes without manually rebasing each one. Most relevant for teams using rebase-based workflows before Git 2.9+ made this workflow easier.

Abandoned/unmaintained as of the last major update. The project is explicitly marked NOT MAINTAINED in the repo description, with the author noting Git 2.9+ now provides equivalent functionality via git pull --rebase --autostash. No recent commits visible in the file structure, and the README recommends using native Git aliases instead.

High risk for active use: the project has zero maintenance, Git workflow defaults have shifted making it less necessary, and Ruby gem dependencies are likely outdated. Windows support is explicitly broken (no native spawn support). Single-author project with no active community. Safe only for legacy codebases already using it or as historical reference.

Nothing. The project is explicitly not maintained. The README's WARNINGS section recommends users switch to Git 2.9+ built-in features (git config --global alias.up 'pull --rebase --autostash') instead of using this tool.

git clone https://github.com/aanand/git-up.git
cd git-up
bundle install
bundle exec bin/git-up

Or install as a gem: gem install git-up (though this is not recommended per the README).

Daily commands: After bundle install, run bundle exec bin/git-up from within a git repository. Or if installed via rubygems, simply git-up from any git repo. The tool operates on the current directory's git state and has no server component.

• bin/git-up — Entry point executable that users invoke; defines the command-line interface and orchestrates the git-up workflow.
• lib/git-up.rb — Core library file containing the main logic for fetching and rebasing remote branches; the heart of the tool.
• lib/git-up/version.rb — Version definition file; required for gem packaging and release management.
• git-up.gemspec — Gem specification file defining dependencies, metadata, and build configuration for distribution.
• README.md — Comprehensive documentation explaining the tool's purpose, maintenance status, and modern Git alternatives; essential context for all contributors.
• Gemfile — Dependency manifest defining runtime and development gem requirements for the project.

• bin/git-up (CLI Entry Point) (Ruby, shell) — Parses command-line arguments, loads the core library, orchestrates the main workflow, and displays results to the user.
  • Failure mode: Inability to invoke; missing executable bit, Ruby not in PATH, or file corruption.
• lib/git-up.rb (Core Logic) (Ruby, Git CLI) — Implements all Git operations: fetching remotes, listing branches, rebasing, stashing, and error handling for the workflow.
  • Failure mode: Rebase conflicts, network errors during fetch, or diverged branches causing failed rebases.
• Git Repository (External) (Git) — The actual local Git repository on which git-up operates; contains branches, remotes, and working tree state.
  • Failure mode: Corrupted refs, detached HEAD state, or missing remote tracking branches.

• User shell → bin/git-up — Command invocation with optional arguments
• bin/git-up → lib/git-up.rb — Ruby code loading and initialization
• lib/git-up.rb → Git repository — Git CLI commands: branch listing, fetch, checkout, rebase
• Git repository → lib/git-up.rb — Command output: branch names, rebase status, error messages
• lib/git-up.rb → bin/git-up — Return operation results and exit status
• bin/git-up → User shell — Print summary output and exit code

Add a new Git operation

1. Define the operation method in the main logic class (lib/git-up.rb)
2. Call the new method from the appropriate workflow step in the CLI execution (bin/git-up)
3. Update the man page with the new behavior (man/git-up.1)

Update version and release

1. Bump the version constant (lib/git-up/version.rb)
2. Ensure gemspec references are consistent (git-up.gemspec)
3. Use Rakefile to build and release the gem (Rakefile)

Modify dependency requirements

1. Update gem dependencies in the gemspec file (git-up.gemspec)
2. Run bundle to lock versions (Gemfile)
3. Test in Docker environment for consistency (Dockerfile)

• Ruby — Lightweight scripting language ideal for command-line Git automation tools; strong subprocess and shell integration capabilities.
• RubyGems — Standard Ruby packaging mechanism for easy installation via gem install and distribution to users.
• Git CLI — Direct invocation of native Git commands ensures compatibility with all Git versions and configurations without reimplementing Git logic.
• Docker — Provides reproducible development and testing environments across different systems and Git versions.

• Direct Git CLI invocation rather than a Git library binding

  • Why: Simpler implementation and guaranteed compatibility; avoids managing a heavyweight dependency.
  • Consequence: Slower execution due to process spawning overhead; harder to capture partial progress or streaming output.

• Monolithic logic in lib/git-up.rb rather than modular subcomponents

  • Why: Smaller codebase, easier to understand for a single-purpose tool; reduces boilerplate.
  • Consequence: Less extensibility; harder to test individual operations in isolation; coupling between concerns.

• No configuration file or advanced options

  • Why: Simple, predictable behavior suitable for the common workflow; reduces cognitive load on users.
  • Consequence: Users with non-standard workflows cannot customize behavior; no per-repository settings.

• Does not maintain or support interactive conflict resolution; user must manually resolve rebase conflicts.
• Does not support Windows natively (shell script based; requires bash/Unix environment).
• Does not provide real-time monitoring or watch mode for continuous branch updates.
• Not maintained as of the README notice; superseded by native Git 2.9+ features (git pull --rebase --autostash).

• Avg cyclomatic complexity: ~6 — Procedural script with straightforward Git command invocation; minimal abstraction layers; cyclomatic complexity low due to single-path main workflow.
• Largest file: lib/git-up.rb (250 lines)
• Estimated quality issues: ~4 — Missing error recovery, no unit tests visible, sparse documentation in code, subprocess invocation without detailed logging or error messages.

• Subprocess error handling via exit status only (Medium) — lib/git-up.rb: Git operations invoked without detailed error capture; failures may be silent or ambiguous without parsing stderr.
• Global state mutation in rebase loop (High) — lib/git-up.rb: Rebasing each branch in sequence modifies working tree state; a failure mid-loop leaves repository in inconsistent state.
• No dry-run or preview mode (Medium) — bin/git-up: Tool immediately applies rebase changes; users cannot preview what will happen before committing to the operation.

• lib/git-up.rb (git fetch step) (I/O bound) — Network I/O for fetching all remotes; scales with number of remotes and repository size; blocking operation.
• lib/git-up.rb (rebase per-branch) (CPU bound + I/O bound) — Sequential rebase of each tracked branch; no parallelization; total time is sum of all rebases.
• bin/git-up (Ruby subprocess spawning) (Process overhead) — Each Git command spawns a new process; overhead of process creation and shell parsing for every operation.

RVM compatibility: users with RVM may hit spawn.rb:187 ArgumentError (documented in RVM.md). Windows is completely unsupported with no native spawn support; a Python port exists as alternative. The git-up.bundler.check config option requires bundler integration. Git version expectations: tool was built for Git <2.0 behavior; Git 2.9+ users should use built-in --rebase --autostash instead. Configuration via git config git-up.* keys must be set before running the tool.

• Git Rebase vs. Merge — The entire purpose of git-up is to rebase instead of merge when updating from remotes, so understanding the tradeoffs (linear history vs. merge commit preservation) is fundamental to why this tool exists
• Git Autostash — git-up likely uses or reimplements git's autostash feature to automatically stash/restore uncommitted changes during rebase, a core convenience feature making the tool safer to use
• Remote-Tracking Branches — The tool operates on all locally-tracked remote branches (like origin/main, origin/feature), not just the current branch, requiring understanding of how git tracks remote state locally
• Git Configuration Namespacing — git-up uses git's config system with namespaced keys (git-up.*) for per-project and global settings; understanding this pattern is needed to configure the tool

• msiemens/PyGitUp — Official Python port of git-up, created specifically to provide Windows support that the Ruby version lacks
• tj/git-extras — Similar Git workflow tool that provides additional git commands and integrates with common branching patterns
• nvie/gitflow — Popular Git workflow tool that handles branch management and releases, addressing overlapping multi-branch coordination problems
• github/hub — GitHub-aware CLI wrapper around git that handles similar multi-branch operations with GitHub-specific features
• golang/go — Uses a rebase-based workflow internally; go get uses similar patterns that inspired git-up's design for clean commit histories

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive RSpec unit tests for lib/git-up.rb core functionality

The repo lacks visible test files despite being a Ruby gem with complex git operations. The main library file (lib/git-up.rb) handles branch fetching, rebasing, and stashing logic that should have unit test coverage to prevent regressions and document expected behavior.

• [ ] Create spec/ directory with spec_helper.rb for test configuration
• [ ] Write unit tests in spec/git-up_spec.rb covering: branch detection, rebase logic, autostash functionality, and error handling
• [ ] Add RSpec gem to Gemfile if not present, and update Rakefile to include test task
• [ ] Verify tests pass locally with rake spec

Create GitHub Actions workflow for Ruby gem testing and linting

The repo has a Dockerfile and docker-compose.yml suggesting CI was considered, but no GitHub Actions workflow exists. A workflow would validate the gem across multiple Ruby versions and catch breaking changes early.

• [ ] Create .github/workflows/test.yml with matrix testing for Ruby 2.7, 3.0, 3.1+
• [ ] Include linting steps using Rubocop (add to Gemfile as dev dependency if needed)
• [ ] Run bundle install and rake spec in the workflow
• [ ] Verify workflow triggers on push and pull_request to main/master branches

Update and complete the man/git-up.1 manual page with full DESCRIPTION and EXAMPLES sections

The README.md snippet shows the manual file exists but the SYNOPSIS section appears truncated in the file listing. The man page should document the tool's behavior comprehensively given the README already explains why it's deprecated but hasn't been removed from the repo.

• [ ] Review current man/git-up.1 content to identify missing sections
• [ ] Add complete DESCRIPTION section explaining branch tracking and rebasing behavior
• [ ] Add EXAMPLES section showing: basic usage, interaction with autostash, comparison to git pull --rebase --autostash
• [ ] Add DEPRECATION NOTICE section at the end referencing the README recommendations for Git 2.9+
• [ ] Verify man page renders correctly with man -l man/git-up.1

• Add test coverage for the core rebase logic in lib/git-up.rb—no test directory is visible in the file structure, making this a clean addition point for a new contributor to learn the codebase
• Document the exact behavior of the git-up.bundler.check configuration option with examples in the README, as it's mentioned but incompletely explained in the current snippet
• Create a migration guide in the README showing equivalent commands for Git 2.9+ users (e.g., shell alias setup), making the deprecation path clearer for existing users

This project has critical security issues and should not be used. The primary concerns are: (1) use of Ruby 2.1.3 from 2013 with ~10 years of unpatched vulnerabilities, (2) the project is explicitly unmaintained with no security updates, (3) missing or unreviewed dependency lock file, and (4) container running as root. The project's own README recommends using native Git features instead. For any systems currently using this tool, immediate migration away is strongly advised.

• Critical · Outdated Ruby Base Image — Dockerfile, line 1. The Dockerfile uses Ruby 2.1.3, released in September 2013. This version reached end-of-life in December 2014 and has not received security updates for nearly a decade. It contains numerous known vulnerabilities including CVEs in the Ruby runtime itself. Fix: Update to Ruby 3.0 or later (preferably the latest stable version). Ruby 2.1.3 should not be used for any production or development purposes.
• High · Missing Gemfile.lock in Repository — Dockerfile, line 8 and git-up.gemspec. The Dockerfile references Gemfile.lock but the dependency content was not provided. Without a locked dependency file, the bundle install command will fetch the latest versions of gems at build time, which could include compromised or vulnerable versions. This breaks reproducibility and increases supply chain risk. Fix: Commit Gemfile.lock to version control and review all gem dependencies for known vulnerabilities. Use tools like bundler-audit to scan for vulnerable gems.
• High · No Security Updates - Unmaintained Project — README.md, Project Status. The project is explicitly marked as NOT MAINTAINED in the description. No security patches or updates have been applied. Any vulnerabilities discovered will not be fixed. Fix: This project should not be used in production environments. Use Git 2.9+ with the native git configuration as suggested in the README instead.
• Medium · Missing Alpine Linux Image — Dockerfile, line 1. The Dockerfile uses the full Ruby image instead of alpine variant, resulting in a larger attack surface and more dependencies than necessary. Fix: Use 'ruby:alpine' or 'ruby:3.2-alpine' as the base image to reduce the attack surface and image size.
• Medium · Root User in Container — Dockerfile. The Dockerfile does not specify a non-root user. The application runs as root inside the container, violating the principle of least privilege. Fix: Add a non-root user and switch to it before running the application: RUN useradd -m appuser && USER appuser
• Low · Missing .dockerignore — Repository root. No .dockerignore file is mentioned in the file structure. Without it, unnecessary files (git history, node_modules, local config, etc.) may be copied into the Docker image. Fix: Create a .dockerignore file to exclude unnecessary files from the Docker build context.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.