sugarjar 2.0.0.beta.1 → 2.0.2

data/README.md

@@ -18,29 +18,31 @@ If you miss Mondrian or Phabricator - this is the tool for you!
 
 If you don't, there's a ton of useful stuff for everyone!
 
-## Installation
-
-Sugarjar is packaged in a variety of Linux distributions - see if it's on the
-list here, and if so, use your package manager (or `gem`) to install it:
-
-[![Packaging status](https://repology.org/badge/vertical-allrepos/sugarjar.svg?exclude_unsupported=1)](https://repology.org/project/sugarjar/versions)
-
-If you are using a Linux distribution version that is end-of-life'd, click the
-above image, it'll take you to a page that lists unsupported distro versions
-as well (they'll have older SugarJar, but they'll probably still have some
-version).
-
-Ubuntu users, Ubuntu versions prior to 24.x cannot be updated, so if you're on
-an older Ubuntu please use [this
-PPA](https://launchpad.net/~michel-slm/+archive/ubuntu/sugarjar) from our
-Ubuntu package maintainer.
-
-For MacOS users, we recommend using Homebrew - SugarJar is now in Homebrew Core.
-
-Finally, if none of those work for you, you can clone this repo and run it
-directly from there.
-
-## Auto cleanup squash-merged branches
+Jump to what you're most interested in:
+
+* [Common Use-cases](#common-use-cases)
+   * [Auto Cleanup Squash-merged branches](#auto-cleanup-squash-merged-branches)
+   * [Smarter clones and remotes](#smarter-clones-and-remotes)
+   * [Work with stacked branches more easily](#work-with-stacked-branches-more-easily)
+   * [Creating Stacked PRs with subfeatures](#creating-stacked-prs-with-subfeatures)
+   * [Have a better lint/unittest experience!](#have-a-better-lintunittest-experience)
+   * [Better push defaults](#better-push-defaults)
+   * [Cleaning up your own history](#cleaning-up-your-own-history)
+   * [Better feature branches](#better-feature-branches)
+   * [Smartlog](#smartlog)
+   * [Sync work across workstations](#sync-work-across-workstations)
+   * [Pulling in suggestions from the web](#pulling-in-suggestions-from-the-web)
+   * [And more!](#and-more)
+* [Installation](#installation)
+* [Configuration](#configuration)
+* [Repository Configuration](#repository-configuration)
+   * [Commit Templates](#commit-templates)
+* [Enterprise GitHub](#enterprise-github)
+* [FAQ](#faq)
+
+## Common Use-cases
+
+### Auto cleanup squash-merged branches
 
 It is common for a PR to go back and forth with a variety of nits, lint fixes,
 typos, etc. that can muddy history. So many projects will "squash and merge"
@@ -49,12 +51,12 @@ doesn't work. Git will tell you the branch isn't fully merged. You can, of
 course `git branch -D <branch>`, but that does no safety checks at all, it
 forces the deletion.
 
-Enter `sj bclean` - it determines if the contents of your branch has been merge
-and safely deletes if so.
+Enter `sj lbclean` - it determines if the contents of your branch has been merge
+and safely deletes if so. (Note: `lbclean` stands for "local branch clean", and
+is aliased to `bclean` for both backwards-compatibility and also since it's the
+most common branch-cleanup command).
 
-``` shell
-sj bclean
-```
+![bclean screenshot](https://github.com/jaymzh/sugarjar/blob/main/images/bclean.png)
 
 Will delete a branch, if it has been merged, **even if it was squash-merged**.
 
@@ -64,44 +66,43 @@ You can pass it a branch if you'd like (it defaults to the branch you're on):
 But it gets better! You can use `sj bcleanall` to remove all branches that have
 been merged:
 
-```shell
-$ git branch
-* argparse
-  master
-  feature
-  hubhost
-$ git bcleanall
-Skipping branch argparse - there are unmerged commits
-Reaped branch feature
-Reaped branch hubhost
-```
+![bcleanall screenshot](https://github.com/jaymzh/sugarjar/blob/main/images/bcleanall.png)
 
-## Smarter clones and remotes
+There is also `sj rbclean` ("remote branch clean") (and `sj rbcleanall`) for
+cleanup of remote branches. *Note*: This cannot differentiate between
+PR/feature branches which have been merged and long-lived release branches that
+have been merged (e.g.  if '2.0-release' is a branch and has no commits not in
+main, it will be deleted).
+
+There is even `sj gbclean` ("global branch clean") (and `sj gbcleanall`) which will
+do both the local and remote cleaning.
+
+*NOTE*: Remote branch cleaning is still experimental, use with caution!
+
+### Smarter clones and remotes
 
 There's a pattern to every new repo we want to contribute to. First we fork,
 then we clone the fork, then we add a remote of the upstream repo. It's
 monotonous. SugarJar does this for you:
 
-```shell
-sj smartclone jaymzh/sugarjar
-```
+![smartclone screenshot](https://github.com/jaymzh/sugarjar/blob/main/images/sclone.png)
 
-(also `sj sclone`)
+`sj` accepts both `smartclone` and `sclone` for this command.
 
 This will:
 
-* Make a fork of the repo, if you don't already have one
+* Fork the repo to your personal org (if you don't already have a fork)
 * Clone your fork
 * Add the original as an 'upstream' remote
 
 Note that it takes short names for repos. No need to specify a full URL,
 just a $org/$repo.
 
-Like `git clone`, `sj sclone` will accept an additional argument as the
+Like `git clone`, `sj smartclone` will accept an additional argument as the
 destination directory to clone to. It will also pass any other unknown options
 to `git clone` under the hood.
 
-## Work with stacked branches more easily
+### Work with stacked branches more easily
 
 It's important to break changes into reviewable chunks, but working with
 stacked branches can be confusing. SugarJar provides several tools to make this
@@ -111,122 +112,75 @@ First, and foremost, is `feature` and `subfeature`. Regardless of stacking, the
 way to create a new feature bracnh with sugarjar is with `sj feature` (or `sj
 f` for short):
 
-```shell
-$ sj feature mynewthing
-Created feature branch mynewthing based on origin/main
-```
+![feature screenshot](https://github.com/jaymzh/sugarjar/blob/main/images/feature.png)
 
-A "feature" in SugarJar parliance just means that the branch is always created
-from "most_main" - this is usually "upstream/main", but SJ will figure out
-which remote is the "upstream", even if it's "origin", and then will determine
-the primary branch ("main" or for older repos "master"). It's also smart enough
+A "feature" in SugarJar parlance just means that the branch is always created
+from "most main" - this is usually `upstream/main`, but SJ will figure out
+which remote is the "upstream", even if it's `origin`, and then will determine
+the primary branch (`main` or for older repos `master`). It's also smart enough
 to fetch that remote first to make sure you're working on the latest HEAD.
 
-When you want to create a stacked PR, you can create "subfeature", which, at
+When you want to create a stacked PR, you can create `subfeature`, which, at
 its core is just a branch created from the current branch:
 
-```shell
-$ sj subfeature dependentnewthing
-Created feature branch dependentnewthing based on mynewthing
-```
+![subfeature screenshot](https://github.com/jaymzh/sugarjar/blob/main/images/subfeature.png)
 
 If you create branches like this then sugarjar can now make several things
 much easier:
 
 * `sj up` will rebase intelligently
 * After an `sj bclean` of a branch earlier in the tree, `sj up` will update
-  the tracked branch to "most_main"
+  the tracked branch to "most main"
 
 There are two commands that will show you the state of your stacked branches:
 
 * `sj binfo` - shows the current branch and its ancestors up to your primary branch
-* `sj smartlist` (aka `sj sl`) - shows you the whole tree.
+* `sj smartlog` (aka `sj sl`) - shows you the whole tree.
 
-To continue with the example above, my `smartlist` might look like:
+To continue with the example above, my `smartlog` might look like:
 
-```text
-$ sj sl
-* 59c0522 (HEAD -> dependentnewthing) anothertest
-* 6ebaa28 (mynewthing) test
-o 7a0ffd0 (tag: v1.1.2, origin/main, origin/HEAD, main) Version bump (#160)
-```
+![subfeature-smartlog screenshot](https://github.com/jaymzh/sugarjar/blob/main/images/subfeature-smartlog.png)
 
-This is simple. Now lets make a different feature stack:
+As you can see, `mynewthing` is derived from `main`, and `dependentnewthing` is
+derived from `mynewthing`.
 
-```text
-$ sj feature anotherfeature
-Created feature branch anotherfeature based on origin/main
-# do stuff
-$ sj subfeature dependent2
-Created feature branch dependent2 based on anotherfeature
-# do stuff
-```
+Now lets make a different feature stack:
 
-The `smartlist` will now show us this tree, and it's a bit more interesting:
+![subfeature-part2 screenshot](https://github.com/jaymzh/sugarjar/blob/main/images/subfeature-part2.png)
 
-```text
-$ sj sl
-* af6f143 (HEAD -> dependent2) morestuff
-* 028c7f4 (anotherfeature) stuff
-| * 59c0522 (dependentnewthing) anothertest
-| * 6ebaa28 (mynewthing) test
-|/
-o 7a0ffd0 (tag: v1.1.2, origin/main, origin/HEAD, main) Version bump (#160)
-```
+The `smartlog` will now show us this tree, and it's a bit more interesting:
 
-Now, what happens if I make a change to `mynewthing`?
+![subfeature-part2-smartlog screenshot](https://github.com/jaymzh/sugarjar/blob/main/images/subfeature-part2-smartlog.png)
 
-```text
-$ sj co mynewthing
-Switched to branch 'mynewthing'
-Your branch is ahead of 'origin/main' by 1 commit.
-  (use "git push" to publish your local commits)
-$ echo 'randomchange' >> README.md
-$ git commit -a -m change
-[mynewthing d33e082] change
- 1 file changed, 1 insertion(+)
-$ sj sl
-* d33e082 (HEAD -> mynewthing) change
-| * af6f143 (dependent2) morestuff
-| * 028c7f4 (anotherfeature) stuff
-| | * 59c0522 (dependentnewthing) anothertest
-| |/
-|/|
-* | 6ebaa28 test
-|/
-o 7a0ffd0 (tag: v1.1.2, origin/main, origin/HEAD, main) Version bump (#160)
-```
+Here we can see from `main`, we have two branches: one going to `mynewthing`
+and one going to `anotherfeature`. Each of those has their own dependent branch
+on top.
+
+Now, what happens if I make a change to `mynewthing` (the bottom of the first stack)?
+
+![subfeature-part3 screenshot](https://github.com/jaymzh/sugarjar/blob/main/images/subfeature-part3.png)
 
 We can see here now that `dependentnewthing`, is based off a commit that _used_
-to be `mynewthing`, but `mynewthing` has moved. But SugarJar will handle this
-all correctly when we ask it to update the branch:
+to be `mynewthing` (`5086ee`), but `mynewthing` has moved. Both `mynewthing`
+and `dependentnewthing` are derived from `5086ee` (the old `mynewthing`), but
+`dependentnewthing` isn't (yet) based on the current `mynewthing`. But SugarJar
+will handle this all correctly when we ask it to update the branch:
 
-```text
-$ sj co dependentnewthing
-Switched to branch 'dependentnewthing'
-Your branch and 'mynewthing' have diverged,
-and have 1 and 1 different commits each, respectively.
-  (use "git pull" if you want to integrate the remote branch with yours)
-$ sj up
-dependentnewthing rebased on mynewthing
-$ sj sl
-* 93ed585 (HEAD -> dependentnewthing) anothertest
-* d33e082 (mynewthing) change
-* 6ebaa28 test
-| * af6f143 (dependent2) morestuff
-| * 028c7f4 (anotherfeature) stuff
-|/
-o 7a0ffd0 (tag: v1.1.2, origin/main, origin/HEAD, main) Version bump (#160)
-```
+![subfeature-part3-rebase screenshot](https://github.com/jaymzh/sugarjar/blob/main/images/subfeature-part3-rebase.png)
+
+Here we see that SugarJar knew that `dependentnewthing` should be rebased onto
+`mynewthing`, and it did the right thing - from main there's still the
+`50806ee` _and_ the new additional change which are now both part of the
+`mynewthing` branch, and `dependentnewthing` is based on that branch, this
+including all 3 commits in the right order.
 
 Now, lets say that `mynewthing` gets merged and we use `bclean` to clean it all
 up, what happens then?
 
-```text
-$ sj up
-The brach we were tracking is gone, resetting tracking to origin/main
-dependentnewthing rebased on origin/main
-```
+![subfeature-detect-missing-base screenshot](https://github.com/jaymzh/sugarjar/blob/main/images/subfeature-detect-missing-base.png)
+
+SugarJar detects that branch is gone and thus this branch should now be based
+on the upstream main branch!
 
 ### Creating Stacked PRs with subfeatures
 
@@ -242,12 +196,12 @@ It looks like this is a subfeature, would you like to base this PR on mynewthing
 ...
 ```
 
-## Have a better lint/unittest experience!
+### Have a better lint/unittest experience!
 
 Ever made a PR, only to find out later that it failed tests because of some
 small lint issue? Not anymore! SJ can be configured to run things before
 pushing. For example,in the SugarJar repo, we have it run Rubocop (ruby lint)
-and Markdownlint "on_push". If those fail, it lets you know and doesn't push.
+and Markdownlint `on_push`. If those fail, it lets you know and doesn't push.
 
 You can configure SugarJar to tell it how to run both lints and unittests for
 a given repo and if one or both should be run prior to pushing.
@@ -255,31 +209,31 @@ a given repo and if one or both should be run prior to pushing.
 The details on the config file format is below, but we provide three commands:
 
 ```shell
-git lint
+sj lint
 ```
 
 Run all linters.
 
 ```shell
-git unit
+sj unit
 ```
 
 Run all unittests.
 
 ```shell
-git smartpush # or spush
+sj smartpush # or spush
 ```
 
 Run configured push-time actions (nothing, lint, unit, both), and do not
 push if any of them fail.
 
-## Better push defaults
+### Better push defaults
 
 In addition to running pre-push tests for you `smartpush` also picks smart
 defaults for push. So if you `sj spush` with no arguments, it uses the
 `origin` remote and the same branch name you're on as the remote branch.
 
-## Cleaning up your own history
+### Cleaning up your own history
 
 Perhaps you contribute to a project that prefers to use merge commits, so you
 like to clean up your own history. This is often difficult to get right - a
@@ -299,7 +253,7 @@ command is a mouthful! Enter `sj fpush`. It has all the smarts of `sj
 smartpush` (runs configured pre-push actions), but adds `--force-with-lease` to
 the command!
 
-## Better feature branches
+### Better feature branches
 
 When you want to start a new feature, you want to start developing against
 latest. That's why `sj feature` defaults to creating a branch against what we
@@ -328,14 +282,29 @@ use branch-based workflows and branches need to be prefixed with e.g. `$USER/`.
 For example, if your prefix was `user/`, then `sj feature foo` would create
 `user/foo`, and `sj co foo` would switch to `user/foo`.
 
-## Smartlog
+### Smartlog
 
 Smartlog will show you a tree diagram of your branches! Simply run `sj
 smartlog` or `sj sl` for short.
 
-![smartlog screenshot](https://github.com/jaymzh/sugarjar/blob/main/smartlog.png)
+![smartlog screenshot](https://github.com/jaymzh/sugarjar/blob/main/images/smartlog.png)
+
+### Sync work across workstations
 
-## Pulling in suggestions from the web
+If you work on multiple workstations, keeping your branches in-sync can be a
+pain. SugarJar provides `sync` to help with this.
+
+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`.
+
+It's very similar to `sj up`, but instead of rebasing on top of the tracking
+branch, it rebases on top of the push target branch.
+
+### Pulling in suggestions from the web
 
 When someone 'suggests' a change in the GitHub WebUI, once you choose to commit
 them, your origin and local branches are no longer in-sync. The
@@ -344,23 +313,42 @@ local branch. This command will show a diff and ask for confirmation before
 attempting the merge and  - if allowed to continue - will use a fast-forward
 merge.
 
-## And more!
+### And more!
 
 See `sj help` for more commands!
 
+## Installation
+
+Sugarjar is packaged in a variety of Linux distributions - see if it's on the
+list here, and if so, use your package manager (or `gem`) to install it:
+
+[![Packaging status](https://repology.org/badge/vertical-allrepos/sugarjar.svg?exclude_unsupported=1)](https://repology.org/project/sugarjar/versions)
+
+If you are using a Linux distribution version that is end-of-life'd, click the
+above image, it'll take you to a page that lists unsupported distro versions
+as well (they'll have older SugarJar, but they'll probably still have some
+version).
+
+Ubuntu users, Ubuntu versions prior to 24.x cannot be updated, so if you're on
+an older Ubuntu please use [this
+PPA](https://launchpad.net/~michel-slm/+archive/ubuntu/sugarjar) from our
+Ubuntu package maintainer.
+
+For MacOS users, we recommend using Homebrew - SugarJar is now in Homebrew Core.
+
+Finally, if none of those work for you, you can clone this repo and run it
+directly from there.
+
 ## Configuration
 
 Sugarjar will read in both a system-level config file
 (`/etc/sugarjar/config.yaml`) and a user-level config file
-`~/.config/sugarjar/config.yaml`, if they exist. Anything in the user config
+(`~/.config/sugarjar/config.yaml`), if they exist. Anything in the user config
 will override the system config, and command-line options override both. The
-yaml file is a straight key-value pair of options without their '--'. For
-example:
+yaml file is a straight key-value pair of options without their '--'.
 
-```yaml
-log_level: debug
-github_user: jaymzh
-```
+See [examples/sample_config.yaml](examples/sample_config.yaml) for an example
+configuration file.
 
 In addition, the environment variable `SUGARJAR_LOGLEVEL` can be defined to set
 a log level. This is primarily used as a way to turn debug on earlier in order to
@@ -378,43 +366,10 @@ ignore_deprecated_options:
 ## Repository Configuration
 
 Sugarjar looks for a `.sugarjar.yaml` in the root of the repository to tell it
-how to handle repo-specific things. Currently there options are:
-
-* `lint` - A list of scripts to run on `sj lint`. These should be linters like
-  rubocop or pyflake. Linters will be run from the root of the repo.
-* `lint_list_cmd` - A command to run which will print out linters to run, one
-  per line. Takes precedence over `lint`. The command (and the resulting
-  linters) will be run from the root of the repo.
-* `unit` - A list of scripts to run on `sj unit`. These should be unittest
-  runners like rspec or pyunit. Test will be run from the root of the repo.
-* `unit_list_cmd` - A command to run which will print out the unit tests to
-  run, one more line. Takes precedence over `unit`. The command (and the
-  resulting unit tests) will be run from the root of the repo.
-* `on_push` - A list of types (`lint`, `unit`) of checks to run before pushing.
-  It is highly recommended this is only `lint`. The goal here is to allow for
-  the user to get quick stylistic feedback before pushing their branch to avoid
-  the push-fix-push-fix loop.
-* `commit_template` - A path to a commit template to set in the `commit.template`
-  git config for this repo. Should be either a fully-qualified path, or a path
-  relative to the repo root.
-* `include_from` - This will read an additional repoconfig file and merge it
-  into the one being read. The value should be relative to the root of the
-  repo. This will not error if the file does not exist, it is intended for
-  organizations to allow users to optionally extend a default repo config.
-* `overwrite_from` - Same as `include_from`, but completely overwrites the
-  base configuration if the file is found.
-
-Example configuration:
-
-```yaml
-lint:
-  - scripts/lint
-unit:
-  - scripts/unit
-on_push:
-  - lint
-commit_template: .commit-template.txt
-```
+how to handle repo-specific things. See
+[examples/sample_repoconfig.yaml](examples/sample_repoconfig.yaml) for an
+example configuration that walks through all valid repo configurations in
+detail.
 
 ### Commit Templates
 
@@ -471,9 +426,9 @@ it on Windows, but I'll happily accept patches for Windows compatibility.
 
 **How do I get tab-completion?**
 
-If the package for your OS/distro didn't set it up manually, you should find
-that `sugarjar_completion.bash` is included in the package, and you can simply
-source that in your dotfiles, assuming you are using bash.
+If the package for your OS/distro didn't set it up automatically, you should
+find that `sugarjar_completion.bash` is included in the package, and you can
+simply source that in your dotfiles, assuming you are using bash.
 
 **What happens now that Sapling is released?**
 
@@ -485,4 +440,4 @@ Sapling is a great tool and solves a variety of problems SugarJar will never be
 able to. However, it is a significant workflow change, that won't be
 appropriate for all users or use-cases. Similarly there are workflows and tools
 that Sapling breaks. So worry not, SugarJar will continue to be maintained and
-developed
+developed.

data/bin/sj

@@ -118,15 +118,6 @@ COMMANDS:
               Same as "amend" but without changing the message. Alias for
               "git commit --amend --no-edit".
 
-  bclean [<branch>]
-              If safe, delete the current branch (or the specified branch).
-              Unlike "git branch -d", bclean can handle squash-merged branches.
-              Think of it as a smarter "git branch -d".
-
-  bcleanall
-              Walk all branches, and try to delete them if it's safe. See
-              "bclean" for details.
-
   binfo
               Verbose information about the current branch.
 
@@ -157,14 +148,62 @@ COMMANDS:
               branches. Very convenient for keeping the branch behind a pull-
               request 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.
+
+              Safely clean all branches, both local and remote.  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.
@@ -190,6 +229,20 @@ COMMANDS:
   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.
 

data/examples/sample_config.yaml

@@ -0,0 +1,24 @@
+# This is a sample SugarJar config
+#
+# SugarJar will look for this config in:
+#
+# - /etc/sugarjar/config.yaml
+# - ~/.config/sugarjar/config.yaml
+#
+# The latter will overwrite anything in the former.
+#
+
+# NOTE: This file does NOT document ALL options since any command-line option
+# to SugarJar is a valid configuration in this file, so see `sj help` for full
+# details.
+
+# Autofill in my PRs from my commit message (default: true)
+pr_autofile: true
+
+# Auto stack PRs when subfeatures are detected (default is `nil`, which prompts,
+# but use `true` or `false` to force an option without prompting)
+pr_autostack: true
+
+# Don't warn about deprecated config file options if they are in this
+# list
+ignore_deprecated_options: [ 'gh_cli' ]