Scroll to navigation

SJ(1) User Commands SJ(1)

NAME

sj - SugarJar, a Git/GitHub helper

SYNOPSIS

sj <command> [<args>] [<options>]

DESCRIPTION

Command, args, and options, can appear in any order.

OPTIONS:

Prefix to use for feature branches
The host for "hub". Note that we will set this in the local repo config so there is no need to have multiple config files for multiple github servers. Put your default one in your config file, and simply specify this option the first time you clone or touch a repo and it will be part of that repo until changed.
Github username
Print this help message
Tell command that check for a dirty repo to carry on anyway. [default: false]
Ignore preprun failure on *push commands. [default: false]
Set logging level (fatal, error, warning, info, debug, trace). This can also be set via the SUGARJAR_LOGLEVEL environment variable. [default: info]
--[no-]pr-autofill
When creating a PR, auto fill the title & description from the top commit if we are using "gh". [default: true]
--[no-]pr-autostack
When creating a PR, if this is a subfeature, should we make it a PR on the PR for the parent feature. If not specified, we prompt when this happens, when true always do this, when false never do this. Only applicable when usiing "gh" and on branch-based PRs.
--[no-]color
Enable color. [default: true]

--version

COMMANDS:

amend
Amend the current commit. Alias for "git commit --amend". Accepts other arguments such as "-a" or files.
amendq, qamend
Same as "amend" but without changing the message. Alias for "git commit --amend --no-edit".
binfo
Verbose information about the current branch.
br
Verbose branch list. An alias for "git branch -v".
debuginfo
Prints out a bunch of version and config information useful for including in bug reports.
feature, f <branch_name>
Create a "feature" branch. It's morally equivalent to "git checkout -b" except it defaults to creating it based on some form of 'master' instead of your current branch. In order of preference it will be upstream/master, origin/master, master, depending upon what remotes are available.
Note that you can specify "--feature-prefix" (or add "feature_prefix" to your config) to have all features created with a prefix. This is useful for branch-based workflows where developers are expected to create branches names that, for example, start with their username.
forcepush, fpush
The same as "smartpush", but uses "--force-with-lease". This is a "safer" way of doing force-pushes and is the recommended way to push after rebasing or amending. Never do this to shared branches. Very convenient for keeping the branch behind a pullrequest clean.
globalbranchclean, gbclean [<branch>] [<remote>]
WARNING: EXPERIMENTAL COMMAND.
Combination of "lbclean" and "rbclean". Cleans up both local and remote branches safely. See those commands for details.
globalbranchcleanall, gbcleanall [<remote>]
WARNING: EXPERIMENTAL COMMAND.
See "gbclean"
for details.
lint
Run any linters configured in .sugarjar.yaml.
localbranchclean, lbclean [<branch>]
If safe, delete the current branch (or the specified branch). Unlike "git branch -d", lbclean can handle squash-merged branches. Think of it as a smarter "git branch -d".
Aliased to 'bclean' for backwards compatibility.
localbranchcleanall, lbcleanall
Walk all branches, and try to delete them if it's safe. See "lbclean" for details.
Aliased to 'bcleanall' for backwards compatibility.
pullsuggestions, ps
Pull any suggestions *that have been committed* in the GitHub UI. This will show the diff and prompt for confirmation before merging. Note that a fast-forward merge will be used.
remotebranchclean, rbclean [<branch>] [<remote>]
WARNING: EXPERIMENTAL COMMAND.
Similar to lbclean, except safely cleans up remote branches. Unlike many git commands, <remote> comes after <branch> so that you can specify a branch and the remote defaults to 'origin'. This means you can do "sj rclean" to clean the remote branch with the same name as the local one. Note that you probably want "sclean", which will do both local and remote cleaning in one command.
WARNING: This command cannot differentiate release branches that are fully merged but still need to be kept around for future work. So if main contains everything that 2.0-devel and 3.0-devel has, then those branches will be deleted. Use with caution.
remotebranchcleanall, rbcleanall [<remote>]
WARNING: EXPERIMENTAL COMMAND.
Walk all remote branches, and try to delete them if it's safe. See "rbclean" for details.
smartclone, sclone
A smart wrapper to "git clone" that handles forking and managing remotes for you. It will clone a git repository using hub-style short name ("$org/$repo"). If the org of the repository is not the same as your github-user then it will fork the repo for you to your account (if not already done) and then setup your remotes so that "origin" is your fork and "upstream" is the upstream.
smartlog, sl
Inspired by Facebook's "sl" extension to Mercurial, this command will show you a tree of all your local branches relative to your upstream.
smartpullrequest, smartpr, spr
A smart wrapper to "hub pull-request" that checks if your repo is dirty before creating the pull request.
smartpush, spush
A smart wrapper to "git push" that runs whatever is defined in "on_push" in .sugarjar.yml, and only pushes if they succeed.
subfeature, sf <feature>
An alias for 'sj feature <feature> <current_branch>'
sync
Similar to `up`, except instead of rebasing on a tracked branch (usually `upstream` remote), rebases to wherever our remote push target is (usually `origin` remote). Useful for syncing work across different machines.
For example, if you do some work on feature `foo` on machine1 and push to `origin/foo` (intending to eventually merge to `upstream/main`), then on machine2, you pull that branch, do more work, which you also push to `origin/foo`, then on machine1, you can do `sj sync` to pull down the changes from `origin/foo`. If you have local changes, that are not already on `origin/foo`, those will be rebased on top of the changes from `origin/foo`.
unit
Run any unitests configured in .sugarjar.yaml.
up [<branch>]
Rebase the current branch (or specified branch) intelligently. In most causes this will check for a main (or master) branch on upstream, then origin. If a branch explicitly tracks something else, then that will be used, instead.
upall
Same as "up", but for all branches.
January 2026 FATAL: No such subcommand: version