diff --git a/.github/workflows/check-required-label.yml b/.github/workflows/check-required-label.yml
index 830060fd0..8a2090da7 100644
--- a/.github/workflows/check-required-label.yml
+++ b/.github/workflows/check-required-label.yml
@@ -2,7 +2,7 @@ name: Check Required Labels
on:
pull_request:
- types: [opened, labeled, unlabeled]
+ types: [opened, labeled, unlabeled, synchronize]
jobs:
check-required-label:
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 7f69523ba..a7612deb7 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -1,7 +1,7 @@
name: Continuous Integration
env:
- GO_VERSION: 1.24
+ GO_VERSION: 1.25
on:
push:
@@ -32,7 +32,7 @@ jobs:
- name: Setup Go
uses: actions/setup-go@v5
with:
- go-version: 1.24.x
+ go-version: 1.25.x
- name: Test code
# we're passing -short so that we skip the integration tests, which will be run in parallel below
run: |
@@ -87,7 +87,7 @@ jobs:
- name: Setup Go
uses: actions/setup-go@v5
with:
- go-version: 1.24.x
+ go-version: 1.25.x
- name: Print git version
run: git --version
- name: Test code
@@ -113,7 +113,7 @@ jobs:
- name: Setup Go
uses: actions/setup-go@v5
with:
- go-version: 1.24.x
+ go-version: 1.25.x
- name: Build linux binary
run: |
GOOS=linux go build
@@ -140,7 +140,7 @@ jobs:
- name: Setup Go
uses: actions/setup-go@v5
with:
- go-version: 1.24.x
+ go-version: 1.25.x
- name: Check Vendor Directory
# ensure our vendor directory matches up with our go modules
run: |
@@ -166,12 +166,12 @@ jobs:
- name: Setup Go
uses: actions/setup-go@v5
with:
- go-version: 1.24.x
+ go-version: 1.25.x
- name: Lint
uses: golangci/golangci-lint-action@v8
with:
# If you change this, make sure to also update scripts/golangci-lint-shim.sh
- version: v2.2.1
+ version: v2.4.0
- name: errors
run: golangci-lint run
if: ${{ failure() }}
@@ -187,7 +187,7 @@ jobs:
- name: Setup Go
uses: actions/setup-go@v5
with:
- go-version: 1.24.x
+ go-version: 1.25.x
- name: Download all coverage artifacts
uses: actions/download-artifact@v4
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index abf81551f..65f46ef58 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -70,6 +70,15 @@ jobs:
exit 1
fi
+ - name: Check that docs and schema are up to date
+ run: |
+ if diff -r -q docs docs-master > /dev/null && diff -r -q schema schema-master > /dev/null; then
+ echo "Docs and schema are up to date."
+ else
+ echo "Docs or schema are out of date. Please run 'scripts/update_docs_for_release.sh' and make a PR."
+ exit 1
+ fi
+
- name: Check for Blocking Issues/PRs
if: ${{ !inputs.ignore_blocks }}
id: check_blocks
@@ -139,7 +148,7 @@ jobs:
- name: Setup Go
uses: actions/setup-go@v5
with:
- go-version: 1.24.x
+ go-version: 1.25.x
- name: Run goreleaser
uses: goreleaser/goreleaser-action@v6
diff --git a/.gitignore b/.gitignore
index 9b0ebaef6..ef4dfcac6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -28,3 +28,9 @@ __debug_bin*
demo/output/*
coverage.out
+
+# Nix
+result
+result-*
+.direnv
+.envrc
diff --git a/.golangci.yml b/.golangci.yml
index b217d78a0..c13f7b9f3 100644
--- a/.golangci.yml
+++ b/.golangci.yml
@@ -1,6 +1,6 @@
version: "2"
run:
- go: "1.24"
+ go: "1.25"
linters:
enable:
- copyloopvar
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 3c2bab21d..6c85feab6 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -17,11 +17,12 @@ See [here](./VISION.md) for a set of design principles that we want to consider
## Codebase guide
[This doc](./docs/dev/Codebase_Guide.md) explains:
-* what the different packages in the codebase are for
-* where important files live
-* important concepts in the code
-* how the event loop works
-* other useful information
+
+- what the different packages in the codebase are for
+- where important files live
+- important concepts in the code
+- how the event loop works
+- other useful information
## All code changes happen through Pull Requests
@@ -38,6 +39,16 @@ Please do not raise pull request from your fork's master branch: make a feature
If you've never written Go in your life, then join the club! Lazygit was the maintainer's first Go program, and most contributors have never used Go before. Go is widely considered an easy-to-learn language, so if you're looking for an open source project to gain dev experience, you've come to the right place.
+## Commit history
+
+We value a clean and useful commit history, so please take some time to organize your commits so that they make sense. Don't assume that they will be squashed on merge anyway; we don't do that here.
+
+In particular:
+
+- Refactorings and behavior changes should be in separate commits. There are very few exceptions where this is not possible, but in my experience they are very rare.
+- Strive for minimal commits; every change that is independent from other changes should be in a commit of its own (with a good commit message that explains why the change is made).
+- When you need to iterate over your implementation during review (e.g. because you discovered a bug, or a maintainer requested changes), don't just pile new commits on top. Use fixup commits to make your changes transparent while still maintaining a good commit history. If you don't know what that means, [here's a brief introduction](docs/Fixup_Commits.md).
+
## Running in a VSCode dev container
If you want to spare yourself the hassle of setting up your dev environment yourself (i.e. installing Go, extensions, and extra tools), you can run the Lazygit code in a VSCode dev container like so:
@@ -45,8 +56,9 @@ If you want to spare yourself the hassle of setting up your dev environment your
This requires that:
-* you have docker installed
-* you have the dev containers extension installed in VSCode
+
+- you have docker installed
+- you have the dev containers extension installed in VSCode
See [here](https://code.visualstudio.com/docs/devcontainers/containers) for more info about dev containers.
@@ -60,6 +72,32 @@ To run lazygit from within the integrated terminal just go `go run main.go`
This allows you to contribute to Lazygit without needing to install anything on your local machine. The Codespace has all the necessary tools and extensions pre-installed.
+## Using Nix for development
+
+If you use Nix, you can leverage the included flake to set up a complete development environment with all necessary dependencies:
+
+```sh
+nix develop
+```
+
+This will drop you into a development shell that includes:
+
+- Latest Go toolchain
+- golangci-lint for code linting
+- git and make
+
+You can also build and run lazygit using nix:
+
+```sh
+# Build lazygit
+nix build
+
+# Run lazygit directly
+nix run
+```
+
+The nix flake supports multiple architectures (x86_64-linux, aarch64-linux, x86_64-darwin, aarch64-darwin) and provides a consistent development environment across different systems.
+
## Code of conduct
Please note by participating in this project, you agree to abide by the [code of conduct].
@@ -118,7 +156,7 @@ Lazygit supports [Nerd Fonts](https://www.nerdfonts.com) to render certain icons
## Internationalisation
-Boy that's a hard word to spell. Anyway, lazygit is translated into several languages within the pkg/i18n package.
+Boy that's a hard word to spell. Anyway, lazygit is translated into several languages within the pkg/i18n package.
### For developers adding new text
diff --git a/Dockerfile b/Dockerfile
index 796787a6d..8a18ad8d3 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -2,7 +2,7 @@
# docker build -t lazygit .
# docker run -it lazygit:latest /bin/sh
-FROM golang:1.24 as build
+FROM golang:1.25 as build
WORKDIR /go/src/github.com/jesseduffield/lazygit/
COPY go.mod go.sum ./
RUN go mod download
diff --git a/Makefile b/Makefile
index 513221129..38dc118cb 100644
--- a/Makefile
+++ b/Makefile
@@ -34,11 +34,9 @@ test: unit-test integration-test-all
generate:
go generate ./...
-# If you execute `gofumpt -l -w .`, it will format all Go files in the current directory, including `test/_results/*` files.
-# We pass only Git-tracked Go files to gofumpt because we don't want to format the test results or get errors from it.
.PHONY: format
format:
- git ls-files '*.go' ':!vendor' | xargs gofumpt -l -w
+ gofumpt -l -w .
.PHONY: lint
lint:
diff --git a/README.md b/README.md
index 09385d3fb..656d9d9c6 100644
--- a/README.md
+++ b/README.md
@@ -4,7 +4,7 @@
-
+
@@ -58,7 +58,7 @@ A simple terminal UI for git commands
-
+
## Elevator Pitch
@@ -95,12 +95,16 @@ If you're a mere mortal like me and you're tired of hearing how powerful git is
- [MacPorts](#macports)
- [Void Linux](#void-linux)
- [Scoop (Windows)](#scoop-windows)
+ - [gah (Linux and Mac OS)](#gah-linux-and-mac-os)
- [Arch Linux](#arch-linux)
- - [Fedora and RHEL](#fedora-and-rhel)
+ - [Fedora / Amazon Linux 2023 / CentOS Stream](#fedora--amazon-linux-2023--centos-stream)
- [Solus Linux](#solus-linux)
- [Debian and Ubuntu](#debian-and-ubuntu)
- [Funtoo Linux](#funtoo-linux)
- [Gentoo Linux](#gentoo-linux)
+ - [openSUSE](#opensuse)
+ - [NixOS](#nixos)
+ - [Flox](#flox)
- [FreeBSD](#freebsd)
- [Termux](#termux)
- [Conda](#conda)
@@ -388,19 +392,64 @@ sudo zypper ar https://download.opensuse.org/repositories/devel:/languages:/go/$
sudo zypper ref && sudo zypper in lazygit
```
-### NixOs
+### NixOS
-On NixOs lazygit is packaged with nix and distributed via nixpkgs.
-You can try the lazygit without installing it with:
+#### Using lazygit from nixpkgs
+
+On NixOS, lazygit is packaged with nix and distributed via nixpkgs.
+You can try lazygit without installing it with:
```sh
nix-shell -p lazygit
# or with flakes enabled
nix run nixpkgs#lazygit
```
+Or you can add lazygit to your `configuration.nix` using the `environment.systemPackages` option.
+More details can be found via NixOS search [page](https://search.nixos.org/).
-Or you can add lazygit to you `configuration.nix` using the `environment.systemPackages` option.
-More details can be found via NixOs search [page](https://search.nixos.org/).
+#### Using the official lazygit flake
+
+This repository includes a nix flake that provides the latest development version and additional development tools:
+
+**Run lazygit directly from the repository:**
+```sh
+nix run github:jesseduffield/lazygit
+# or from a local clone
+nix run .
+```
+
+**Build lazygit from source:**
+```sh
+nix build github:jesseduffield/lazygit
+# or from a local clone
+nix build .
+```
+
+**Development environment:**
+For contributors, the flake provides a development shell with Go toolchain, development tools, and dependencies:
+```sh
+nix develop github:jesseduffield/lazygit
+# or from a local clone
+nix develop
+```
+
+The development shell includes:
+- Go toolchain
+- git and make
+- Proper environment variables for development
+
+**Using in other flakes:**
+The flake also provides an overlay for easy integration into other flake-based projects:
+```nix
+{
+ inputs.lazygit.url = "github:jesseduffield/lazygit";
+
+ outputs = { self, nixpkgs, lazygit }: {
+ # Use the overlay
+ nixpkgs.overlays = [ lazygit.overlays.default ];
+ };
+}
+```
### Flox
diff --git a/default.nix b/default.nix
new file mode 100644
index 000000000..c48b1fb8c
--- /dev/null
+++ b/default.nix
@@ -0,0 +1,12 @@
+(import (
+ let
+ lock = builtins.fromJSON (builtins.readFile ./flake.lock);
+ nodeName = lock.nodes.root.inputs.flake-compat;
+ in
+ fetchTarball {
+ url =
+ lock.nodes.${nodeName}.locked.url
+ or "https://github.com/edolstra/flake-compat/archive/${lock.nodes.${nodeName}.locked.rev}.tar.gz";
+ sha256 = lock.nodes.${nodeName}.locked.narHash;
+ }
+) { src = ./.; }).defaultNix
diff --git a/docs-master/Config.md b/docs-master/Config.md
new file mode 100644
index 000000000..da9926b14
--- /dev/null
+++ b/docs-master/Config.md
@@ -0,0 +1,1191 @@
+# User Config
+
+Default path for the global config file:
+
+- Linux: `~/.config/lazygit/config.yml`
+- MacOS: `~/Library/Application\ Support/lazygit/config.yml`
+- Windows: `%LOCALAPPDATA%\lazygit\config.yml` (default location, but it will also be found in `%APPDATA%\lazygit\config.yml`
+
+For old installations (slightly embarrassing: I didn't realise at the time that you didn't need to supply a vendor name to the path so I just used my name):
+
+- Linux: `~/.config/jesseduffield/lazygit/config.yml`
+- MacOS: `~/Library/Application\ Support/jesseduffield/lazygit/config.yml`
+- Windows: `%APPDATA%\jesseduffield\lazygit\config.yml`
+
+If you want to change the config directory:
+
+- MacOS: `export XDG_CONFIG_HOME="$HOME/.config"`
+
+In addition to the global config file you can create repo-specific config files in `/.git/lazygit.yml`. Settings in these files override settings in the global config file. In addition, files called `.lazygit.yml` in any of the parent directories of a repo will also be loaded; this can be useful if you have settings that you want to apply to a group of repositories.
+
+JSON schema is available for `config.yml` so that IntelliSense in Visual Studio Code (completion and error checking) is automatically enabled when the [YAML Red Hat][yaml] extension is installed. However, note that automatic schema detection only works if your config file is in one of the standard paths mentioned above. If you override the path to the file, you can still make IntelliSense work by adding
+
+```yaml
+# yaml-language-server: $schema=https://raw.githubusercontent.com/jesseduffield/lazygit/master/schema/config.json
+```
+
+to the top of your config file or via [Visual Studio Code settings.json config][settings].
+
+[yaml]: https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml
+[settings]: https://github.com/redhat-developer/vscode-yaml#associating-a-schema-to-a-glob-pattern-via-yamlschemas
+
+## Default
+
+This is only meant as a reference for what config options exist, and what their default values are. It is not meant to be copied and pasted into your config file as a whole; that's not a good idea for several reasons. It is recommended to include only those settings in your config file that you actually want to change.
+
+
+```yaml
+# Config relating to the Lazygit UI
+gui:
+ # See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#custom-author-color
+ authorColors: {}
+
+ # See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#custom-branch-color
+ branchColorPatterns: {}
+
+ # Custom icons for filenames and file extensions
+ # See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#custom-files-icon--color
+ customIcons:
+ # Map of filenames to icon properties (icon and color)
+ filenames: {}
+
+ # Map of file extensions (including the dot) to icon properties (icon and color)
+ extensions: {}
+
+ # The number of lines you scroll by when scrolling the main window
+ scrollHeight: 2
+
+ # If true, allow scrolling past the bottom of the content in the main window
+ scrollPastBottom: true
+
+ # See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#scroll-off-margin
+ scrollOffMargin: 2
+
+ # One of: 'margin' (default) | 'jump'
+ scrollOffBehavior: margin
+
+ # The number of spaces per tab; used for everything that's shown in the main
+ # view, but probably mostly relevant for diffs.
+ # Note that when using a pager, the pager has its own tab width setting, so you
+ # need to pass it separately in the pager command.
+ tabWidth: 4
+
+ # If true, capture mouse events.
+ # When mouse events are captured, it's a little harder to select text: e.g.
+ # requiring you to hold the option key when on macOS.
+ mouseEvents: true
+
+ # If true, do not show a warning when amending a commit.
+ skipAmendWarning: false
+
+ # If true, do not show a warning when discarding changes in the staging view.
+ skipDiscardChangeWarning: false
+
+ # If true, do not show warning when applying/popping the stash
+ skipStashWarning: false
+
+ # If true, do not show a warning when attempting to commit without any staged
+ # files; instead stage all unstaged files.
+ skipNoStagedFilesWarning: false
+
+ # If true, do not show a warning when rewording a commit via an external editor
+ skipRewordInEditorWarning: false
+
+ # If true, switch to a different worktree without confirmation when checking out
+ # a branch that is checked out in that worktree
+ skipSwitchWorktreeOnCheckoutWarning: false
+
+ # Fraction of the total screen width to use for the left side section. You may
+ # want to pick a small number (e.g. 0.2) if you're using a narrow screen, so
+ # that you can see more of the main section.
+ # Number from 0 to 1.0.
+ sidePanelWidth: 0.3333
+
+ # If true, increase the height of the focused side window; creating an accordion
+ # effect.
+ expandFocusedSidePanel: false
+
+ # The weight of the expanded side panel, relative to the other panels. 2 means
+ # twice as tall as the other panels. Only relevant if `expandFocusedSidePanel`
+ # is true.
+ expandedSidePanelWeight: 2
+
+ # Sometimes the main window is split in two (e.g. when the selected file has
+ # both staged and unstaged changes). This setting controls how the two sections
+ # are split.
+ # Options are:
+ # - 'horizontal': split the window horizontally
+ # - 'vertical': split the window vertically
+ # - 'flexible': (default) split the window horizontally if the window is wide
+ # enough, otherwise split vertically
+ mainPanelSplitMode: flexible
+
+ # How the window is split when in half screen mode (i.e. after hitting '+'
+ # once).
+ # Possible values:
+ # - 'left': split the window horizontally (side panel on the left, main view on
+ # the right)
+ # - 'top': split the window vertically (side panel on top, main view below)
+ enlargedSideViewLocation: left
+
+ # If true, wrap lines in the staging view to the width of the view. This makes
+ # it much easier to work with diffs that have long lines, e.g. paragraphs of
+ # markdown text.
+ wrapLinesInStagingView: true
+
+ # If true, hunk selection mode will be enabled by default when entering the
+ # staging view.
+ useHunkModeInStagingView: true
+
+ # One of 'auto' (default) | 'en' | 'zh-CN' | 'zh-TW' | 'pl' | 'nl' | 'ja' | 'ko'
+ # | 'ru' | 'pt'
+ language: auto
+
+ # Format used when displaying time e.g. commit time.
+ # Uses Go's time format syntax: https://pkg.go.dev/time#Time.Format
+ timeFormat: 02 Jan 06
+
+ # Format used when displaying time if the time is less than 24 hours ago.
+ # Uses Go's time format syntax: https://pkg.go.dev/time#Time.Format
+ shortTimeFormat: 3:04PM
+
+ # Config relating to colors and styles.
+ # See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#color-attributes
+ theme:
+ # Border color of focused window
+ activeBorderColor:
+ - green
+ - bold
+
+ # Border color of non-focused windows
+ inactiveBorderColor:
+ - default
+
+ # Border color of focused window when searching in that window
+ searchingActiveBorderColor:
+ - cyan
+ - bold
+
+ # Color of keybindings help text in the bottom line
+ optionsTextColor:
+ - blue
+
+ # Background color of selected line.
+ # See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#highlighting-the-selected-line
+ selectedLineBgColor:
+ - blue
+
+ # Background color of selected line when view doesn't have focus.
+ inactiveViewSelectedLineBgColor:
+ - bold
+
+ # Foreground color of copied commit
+ cherryPickedCommitFgColor:
+ - blue
+
+ # Background color of copied commit
+ cherryPickedCommitBgColor:
+ - cyan
+
+ # Foreground color of marked base commit (for rebase)
+ markedBaseCommitFgColor:
+ - blue
+
+ # Background color of marked base commit (for rebase)
+ markedBaseCommitBgColor:
+ - yellow
+
+ # Color for file with unstaged changes
+ unstagedChangesColor:
+ - red
+
+ # Default text color
+ defaultFgColor:
+ - default
+
+ # Config relating to the commit length indicator
+ commitLength:
+ # If true, show an indicator of commit message length
+ show: true
+
+ # If true, show the '5 of 20' footer at the bottom of list views
+ showListFooter: true
+
+ # If true, display the files in the file views as a tree. If false, display the
+ # files as a flat list.
+ # This can be toggled from within Lazygit with the '`' key, but that will not
+ # change the default.
+ showFileTree: true
+
+ # If true, add a "/" root item in the file tree representing the root of the
+ # repository. It is only added when necessary, i.e. when there is more than one
+ # item at top level.
+ showRootItemInFileTree: true
+
+ # If true, show the number of lines changed per file in the Files view
+ showNumstatInFilesView: false
+
+ # If true, show a random tip in the command log when Lazygit starts
+ showRandomTip: true
+
+ # If true, show the command log
+ showCommandLog: true
+
+ # If true, show the bottom line that contains keybinding info and useful
+ # buttons. If false, this line will be hidden except to display a loader for an
+ # in-progress action.
+ showBottomLine: true
+
+ # If true, show jump-to-window keybindings in window titles.
+ showPanelJumps: true
+
+ # Nerd fonts version to use.
+ # One of: '2' | '3' | empty string (default)
+ # If empty, do not show icons.
+ nerdFontsVersion: ""
+
+ # If true (default), file icons are shown in the file views. Only relevant if
+ # NerdFontsVersion is not empty.
+ showFileIcons: true
+
+ # Length of author name in (non-expanded) commits view. 2 means show initials
+ # only.
+ commitAuthorShortLength: 2
+
+ # Length of author name in expanded commits view. 2 means show initials only.
+ commitAuthorLongLength: 17
+
+ # Length of commit hash in commits view. 0 shows '*' if NF icons aren't on.
+ commitHashLength: 8
+
+ # If true, show commit hashes alongside branch names in the branches view.
+ showBranchCommitHash: false
+
+ # Whether to show the divergence from the base branch in the branches view.
+ # One of: 'none' | 'onlyArrow' | 'arrowAndNumber'
+ showDivergenceFromBaseBranch: none
+
+ # Height of the command log view
+ commandLogSize: 8
+
+ # Whether to split the main window when viewing file changes.
+ # One of: 'auto' | 'always'
+ # If 'auto', only split the main window when a file has both staged and unstaged
+ # changes
+ splitDiff: auto
+
+ # Default size for focused window. Can be changed from within Lazygit with '+'
+ # and '_' (but this won't change the default).
+ # One of: 'normal' (default) | 'half' | 'full'
+ screenMode: normal
+
+ # Window border style.
+ # One of 'rounded' (default) | 'single' | 'double' | 'hidden' | 'bold'
+ border: rounded
+
+ # If true, show a seriously epic explosion animation when nuking the working
+ # tree.
+ animateExplosion: true
+
+ # Whether to stack UI components on top of each other.
+ # One of 'auto' (default) | 'always' | 'never'
+ portraitMode: auto
+
+ # How things are filtered when typing '/'.
+ # One of 'substring' (default) | 'fuzzy'
+ filterMode: substring
+
+ # Config relating to the spinner.
+ spinner:
+ # The frames of the spinner animation.
+ frames:
+ - '|'
+ - /
+ - '-'
+ - \
+
+ # The "speed" of the spinner in milliseconds.
+ rate: 50
+
+ # Status panel view.
+ # One of 'dashboard' (default) | 'allBranchesLog'
+ statusPanelView: dashboard
+
+ # If true, jump to the Files panel after popping a stash
+ switchToFilesAfterStashPop: true
+
+ # If true, jump to the Files panel after applying a stash
+ switchToFilesAfterStashApply: true
+
+ # If true, when using the panel jump keys (default 1 through 5) and target panel
+ # is already active, go to next tab instead
+ switchTabsWithPanelJumpKeys: false
+
+# Config relating to git
+git:
+ # Array of pagers. Each entry has the following format:
+ #
+ # # Value of the --color arg in the git diff command. Some pagers want
+ # # this to be set to 'always' and some want it set to 'never'
+ # colorArg: "always"
+ #
+ # # e.g.
+ # # diff-so-fancy
+ # # delta --dark --paging=never
+ # # ydiff -p cat -s --wrap --width={{columnWidth}}
+ # pager: ""
+ #
+ # # e.g. 'difft --color=always'
+ # externalDiffCommand: ""
+ #
+ # # If true, Lazygit will use git's `diff.external` config for paging.
+ # # The advantage over `externalDiffCommand` is that this can be
+ # # configured per file type in .gitattributes; see
+ # # https://git-scm.com/docs/gitattributes#_defining_an_external_diff_driver.
+ # useExternalDiffGitConfig: false
+ #
+ # See https://github.com/jesseduffield/lazygit/blob/master/docs/Custom_Pagers.md
+ # for more information.
+ pagers: []
+
+ # Config relating to committing
+ commit:
+ # If true, pass '--signoff' flag when committing
+ signOff: false
+
+ # Automatic WYSIWYG wrapping of the commit message as you type
+ autoWrapCommitMessage: true
+
+ # If autoWrapCommitMessage is true, the width to wrap to
+ autoWrapWidth: 72
+
+ # Config relating to merging
+ merging:
+ # If true, run merges in a subprocess so that if a commit message is required,
+ # Lazygit will not hang
+ # Only applicable to unix users.
+ manualCommit: false
+
+ # Extra args passed to `git merge`, e.g. --no-ff
+ args: ""
+
+ # The commit message to use for a squash merge commit. Can contain
+ # "{{selectedRef}}" and "{{currentBranch}}" placeholders.
+ squashMergeMessage: Squash merge {{selectedRef}} into {{currentBranch}}
+
+ # list of branches that are considered 'main' branches, used when displaying
+ # commits
+ mainBranches:
+ - master
+ - main
+
+ # Prefix to use when skipping hooks. E.g. if set to 'WIP', then pre-commit hooks
+ # will be skipped when the commit message starts with 'WIP'
+ skipHookPrefix: WIP
+
+ # If true, periodically fetch from remote
+ autoFetch: true
+
+ # If true, periodically refresh files and submodules
+ autoRefresh: true
+
+ # If not "none", lazygit will automatically fast-forward local branches to match
+ # their upstream after fetching. Applies to branches that are not the currently
+ # checked out branch, and only to those that are strictly behind their upstream
+ # (as opposed to diverged).
+ # Possible values: 'none' | 'onlyMainBranches' | 'allBranches'
+ autoForwardBranches: onlyMainBranches
+
+ # If true, pass the --all arg to git fetch
+ fetchAll: true
+
+ # If true, lazygit will automatically stage files that used to have merge
+ # conflicts but no longer do; and it will also ask you if you want to continue a
+ # merge or rebase if you've resolved all conflicts. If false, it won't do either
+ # of these things.
+ autoStageResolvedConflicts: true
+
+ # Command used when displaying the current branch git log in the main window
+ branchLogCmd: git log --graph --color=always --abbrev-commit --decorate --date=relative --pretty=medium {{branchName}} --
+
+ # Commands used to display git log of all branches in the main window, they will
+ # be cycled in order of appearance (array of strings)
+ allBranchesLogCmds:
+ - git log --graph --all --color=always --abbrev-commit --decorate --date=relative --pretty=medium
+
+ # If true, git diffs are rendered with the `--ignore-all-space` flag, which
+ # ignores whitespace changes. Can be toggled from within Lazygit with ``.
+ ignoreWhitespaceInDiffView: false
+
+ # The number of lines of context to show around each diff hunk. Can be changed
+ # from within Lazygit with the `{` and `}` keys.
+ diffContextSize: 3
+
+ # The threshold for considering a file to be renamed, in percent. Can be changed
+ # from within Lazygit with the `(` and `)` keys.
+ renameSimilarityThreshold: 50
+
+ # If true, do not spawn a separate process when using GPG
+ overrideGpg: false
+
+ # If true, do not allow force pushes
+ disableForcePushing: false
+
+ # See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#predefined-commit-message-prefix
+ commitPrefix: []
+
+ # See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#predefined-commit-message-prefix
+ commitPrefixes: {}
+
+ # See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#predefined-branch-name-prefix
+ branchPrefix: ""
+
+ # If true, parse emoji strings in commit messages e.g. render :rocket: as 🚀
+ # (This should really be under 'gui', not 'git')
+ parseEmoji: false
+
+ # Config for showing the log in the commits view
+ log:
+ # One of: 'date-order' | 'author-date-order' | 'topo-order' | 'default'
+ # 'topo-order' makes it easier to read the git log graph, but commits may not
+ # appear chronologically. See https://git-scm.com/docs/
+ #
+ # Can be changed from within Lazygit with `Log menu -> Commit sort order`
+ # (`` in the commits window by default).
+ order: topo-order
+
+ # This determines whether the git graph is rendered in the commits panel
+ # One of 'always' | 'never' | 'when-maximised'
+ #
+ # Can be toggled from within lazygit with `Log menu -> Show git graph` (``
+ # in the commits window by default).
+ showGraph: always
+
+ # displays the whole git graph by default in the commits view (equivalent to
+ # passing the `--all` argument to `git log`)
+ showWholeGraph: false
+
+ # How branches are sorted in the local branches view.
+ # One of: 'date' (default) | 'recency' | 'alphabetical'
+ # Can be changed from within Lazygit with the Sort Order menu (`s`) in the
+ # branches panel.
+ localBranchSortOrder: date
+
+ # How branches are sorted in the remote branches view.
+ # One of: 'date' (default) | 'alphabetical'
+ # Can be changed from within Lazygit with the Sort Order menu (`s`) in the
+ # remote branches panel.
+ remoteBranchSortOrder: date
+
+ # When copying commit hashes to the clipboard, truncate them to this length. Set
+ # to 40 to disable truncation.
+ truncateCopiedCommitHashesTo: 12
+
+# Periodic update checks
+update:
+ # One of: 'prompt' (default) | 'background' | 'never'
+ method: prompt
+
+ # Period in days between update checks
+ days: 14
+
+# Background refreshes
+refresher:
+ # File/submodule refresh interval in seconds.
+ # Auto-refresh can be disabled via option 'git.autoRefresh'.
+ refreshInterval: 10
+
+ # Re-fetch interval in seconds.
+ # Auto-fetch can be disabled via option 'git.autoFetch'.
+ fetchInterval: 60
+
+# If true, show a confirmation popup before quitting Lazygit
+confirmOnQuit: false
+
+# If true, exit Lazygit when the user presses escape in a context where there is
+# nothing to cancel/close
+quitOnTopLevelReturn: false
+
+# Config relating to things outside of Lazygit like how files are opened,
+# copying to clipboard, etc
+os:
+ # Command for editing a file. Should contain "{{filename}}".
+ edit: ""
+
+ # Command for editing a file at a given line number. Should contain
+ # "{{filename}}", and may optionally contain "{{line}}".
+ editAtLine: ""
+
+ # Same as EditAtLine, except that the command needs to wait until the window is
+ # closed.
+ editAtLineAndWait: ""
+
+ # Whether lazygit suspends until an edit process returns
+ editInTerminal: false
+
+ # For opening a directory in an editor
+ openDirInEditor: ""
+
+ # A built-in preset that sets all of the above settings. Supported presets are
+ # defined in the getPreset function in editor_presets.go.
+ editPreset: ""
+
+ # Command for opening a file, as if the file is double-clicked. Should contain
+ # "{{filename}}", but doesn't support "{{line}}".
+ open: ""
+
+ # Command for opening a link. Should contain "{{link}}".
+ openLink: ""
+
+ # CopyToClipboardCmd is the command for copying to clipboard.
+ # See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#custom-command-for-copying-to-and-pasting-from-clipboard
+ copyToClipboardCmd: ""
+
+ # ReadFromClipboardCmd is the command for reading the clipboard.
+ # See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#custom-command-for-copying-to-and-pasting-from-clipboard
+ readFromClipboardCmd: ""
+
+ # A shell startup file containing shell aliases or shell functions. This will be
+ # sourced before running any shell commands, so that shell functions are
+ # available in the `:` command prompt or even in custom commands.
+ # See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#using-aliases-or-functions-in-shell-commands
+ shellFunctionsFile: ""
+
+# If true, don't display introductory popups upon opening Lazygit.
+disableStartupPopups: false
+
+# User-configured commands that can be invoked from within Lazygit
+# See https://github.com/jesseduffield/lazygit/blob/master/docs/Custom_Command_Keybindings.md
+customCommands: []
+
+# See https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#custom-pull-request-urls
+services: {}
+
+# What to do when opening Lazygit outside of a git repo.
+# - 'prompt': (default) ask whether to initialize a new repo or open in the most
+# recent repo
+# - 'create': initialize a new repo
+# - 'skip': open most recent repo
+# - 'quit': exit Lazygit
+notARepository: prompt
+
+# If true, display a confirmation when subprocess terminates. This allows you to
+# view the output of the subprocess before returning to Lazygit.
+promptToReturnFromSubprocess: true
+
+# Keybindings
+keybinding:
+ universal:
+ quit: q
+ quit-alt1:
+ suspendApp:
+ return:
+ quitWithoutChangingDirectory: Q
+ togglePanel:
+ prevItem:
+ nextItem:
+ prevItem-alt: k
+ nextItem-alt: j
+ prevPage: ','
+ nextPage: .
+ scrollLeft: H
+ scrollRight: L
+ gotoTop: <
+ gotoBottom: '>'
+ gotoTop-alt:
+ gotoBottom-alt:
+ toggleRangeSelect: v
+ rangeSelectDown:
+ rangeSelectUp:
+ prevBlock:
+ nextBlock:
+ prevBlock-alt: h
+ nextBlock-alt: l
+ nextBlock-alt2:
+ prevBlock-alt2:
+ jumpToBlock:
+ - "1"
+ - "2"
+ - "3"
+ - "4"
+ - "5"
+ focusMainView: "0"
+ nextMatch: "n"
+ prevMatch: "N"
+ startSearch: /
+ optionMenu:
+ optionMenu-alt1: '?'
+ select:
+ goInto:
+ confirm:
+ confirmMenu:
+ confirmSuggestion:
+ confirmInEditor:
+ confirmInEditor-alt:
+ remove: d
+ new: "n"
+ edit: e
+ openFile: o
+ scrollUpMain:
+ scrollDownMain:
+ scrollUpMain-alt1: K
+ scrollDownMain-alt1: J
+ scrollUpMain-alt2:
+ scrollDownMain-alt2:
+ executeShellCommand: ':'
+ createRebaseOptionsMenu: m
+
+ # 'Files' appended for legacy reasons
+ pushFiles: P
+
+ # 'Files' appended for legacy reasons
+ pullFiles: p
+ refresh: R
+ createPatchOptionsMenu:
+ nextTab: ']'
+ prevTab: '['
+ nextScreenMode: +
+ prevScreenMode: _
+ cyclePagers: '|'
+ undo: z
+ redo: Z
+ filteringMenu:
+ diffingMenu: W
+ diffingMenu-alt:
+ copyToClipboard:
+ openRecentRepos:
+ submitEditorText:
+ extrasMenu: '@'
+ toggleWhitespaceInDiffView:
+ increaseContextInDiffView: '}'
+ decreaseContextInDiffView: '{'
+ increaseRenameSimilarityThreshold: )
+ decreaseRenameSimilarityThreshold: (
+ openDiffTool:
+ status:
+ checkForUpdate: u
+ recentRepos:
+ allBranchesLogGraph: a
+ files:
+ commitChanges: c
+ commitChangesWithoutHook: w
+ amendLastCommit: A
+ commitChangesWithEditor: C
+ findBaseCommitForFixup:
+ confirmDiscard: x
+ ignoreFile: i
+ refreshFiles: r
+ stashAllChanges: s
+ viewStashOptions: S
+ toggleStagedAll: a
+ viewResetOptions: D
+ fetch: f
+ toggleTreeView: '`'
+ openMergeOptions: M
+ openStatusFilter:
+ copyFileInfoToClipboard: "y"
+ collapseAll: '-'
+ expandAll: =
+ branches:
+ createPullRequest: o
+ viewPullRequestOptions: O
+ copyPullRequestURL:
+ checkoutBranchByName: c
+ forceCheckoutBranch: F
+ checkoutPreviousBranch: '-'
+ rebaseBranch: r
+ renameBranch: R
+ mergeIntoCurrentBranch: M
+ moveCommitsToNewBranch: "N"
+ viewGitFlowOptions: i
+ fastForward: f
+ createTag: T
+ pushTag: P
+ setUpstream: u
+ fetchRemote: f
+ addForkRemote: F
+ sortOrder: s
+ worktrees:
+ viewWorktreeOptions: w
+ commits:
+ squashDown: s
+ renameCommit: r
+ renameCommitWithEditor: R
+ viewResetOptions: g
+ markCommitAsFixup: f
+ createFixupCommit: F
+ squashAboveCommits: S
+ moveDownCommit:
+ moveUpCommit:
+ amendToCommit: A
+ resetCommitAuthor: a
+ pickCommit: p
+ revertCommit: t
+ cherryPickCopy: C
+ pasteCommits: V
+ markCommitAsBaseForRebase: B
+ tagCommit: T
+ checkoutCommit:
+ resetCherryPick:
+ copyCommitAttributeToClipboard: "y"
+ openLogMenu:
+ openInBrowser: o
+ viewBisectOptions: b
+ startInteractiveRebase: i
+ selectCommitsOfCurrentBranch: '*'
+ amendAttribute:
+ resetAuthor: a
+ setAuthor: A
+ addCoAuthor: c
+ stash:
+ popStash: g
+ renameStash: r
+ commitFiles:
+ checkoutCommitFile: c
+ main:
+ toggleSelectHunk: a
+ pickBothHunks: b
+ editSelectHunk: E
+ submodules:
+ init: i
+ update: u
+ bulkMenu: b
+ commitMessage:
+ commitMenu:
+```
+
+
+## Platform Defaults
+
+### Windows
+
+```yaml
+os:
+ open: 'start "" {{filename}}'
+```
+
+### Linux
+
+```yaml
+os:
+ open: 'xdg-open {{filename}} >/dev/null'
+```
+
+### OSX
+
+```yaml
+os:
+ open: 'open {{filename}}'
+```
+
+## Custom Command for Opening a Link
+
+```yaml
+os:
+ openLink: 'bash -C /path/to/your/shell-script.sh {{link}}'
+```
+
+Specify the external command to invoke when opening URL links (i.e. creating MR/PR in GitLab, BitBucket or GitHub). `{{link}}` will be replaced by the URL to be opened. A simple shell script can be used to further mangle the passed URL.
+
+## Custom Command for Copying to and Pasting from Clipboard
+
+```yaml
+os:
+ copyToClipboardCmd: ''
+```
+
+Specify an external command to invoke when copying to clipboard is requested. `{{text}` will be replaced by text to be copied. Default is to copy to system clipboard.
+
+If you are working on a terminal that supports OSC52, the following command will let you take advantage of it:
+
+```yaml
+os:
+ copyToClipboardCmd: printf "\033]52;c;$(printf {{text}} | base64 -w 0)\a" > /dev/tty
+```
+
+For tmux you need to wrap it with the [tmux escape sequence](https://github.com/tmux/tmux/wiki/FAQ#what-is-the-passthrough-escape-sequence-and-how-do-i-use-it), and enable passthrough in tmux config with `set -g allow-passthrough on`:
+
+```yaml
+os:
+ copyToClipboardCmd: printf "\033Ptmux;\033\033]52;c;$(printf {{text}} | base64 -w 0)\a\033\\" > /dev/tty
+```
+
+For the best of both worlds, we can let the command determine if we are running in a tmux session and send the correct sequence:
+
+```yaml
+os:
+ copyToClipboardCmd: >
+ if [[ "$TERM" =~ ^(screen|tmux) ]]; then
+ printf "\033Ptmux;\033\033]52;c;$(printf {{text}} | base64 -w 0)\a\033\\" > /dev/tty
+ else
+ printf "\033]52;c;$(printf {{text}} | base64 -w 0)\a" > /dev/tty
+ fi
+```
+
+A custom command for reading from the clipboard can be set using
+
+```yaml
+os:
+ readFromClipboardCmd: ''
+```
+
+It is used, for example, when pasting a commit message into the commit message panel. The command is supposed to output the clipboard content to stdout.
+
+## Configuring File Editing
+
+There are two commands for opening files, `o` for "open" and `e` for "edit". `o` acts as if the file was double-clicked in the Finder/Explorer, so it also works for non-text files, whereas `e` opens the file in an editor. `e` can also jump to the right line in the file if you invoke it from the staging panel, for example.
+
+To tell lazygit which editor to use for the `e` command, the easiest way to do that is to provide an editPreset config, e.g.
+
+```yaml
+os:
+ editPreset: 'vscode'
+```
+
+Supported presets are `vim`, `nvim`, `nvim-remote`, `lvim`, `emacs`, `nano`, `micro`, `vscode`, `sublime`, `bbedit`, `kakoune`, `helix`, `xcode`, `zed` and `acme`. In many cases lazygit will be able to guess the right preset from your $(git config core.editor), or an environment variable such as $VISUAL or $EDITOR.
+
+`nvim-remote` is an experimental preset for when you have invoked lazygit from within a neovim process, allowing lazygit to open the file from within the parent process rather than spawning a new one.
+
+If for some reason you are not happy with the default commands from a preset, or there simply is no preset for your editor, you can customize the commands by setting the `edit`, `editAtLine`, and `editAtLineAndWait` options, e.g.:
+
+```yaml
+os:
+ edit: 'myeditor {{filename}}'
+ editAtLine: 'myeditor --line={{line}} {{filename}}'
+ editAtLineAndWait: 'myeditor --block --line={{line}} {{filename}}'
+ editInTerminal: true
+ openDirInEditor: 'myeditor {{dir}}'
+```
+
+The `editInTerminal` option is used to decide whether lazygit needs to suspend itself to the background before calling the editor. It should really be named `suspend` because for some cases like when lazygit is opened from within a neovim session and you're using the `nvim-remote` preset, you're technically still in a terminal. Nonetheless we're sticking with the name `editInTerminal` for backwards compatibility.
+
+Contributions of new editor presets are welcome; see the `getPreset` function in [`editor_presets.go`](https://github.com/jesseduffield/lazygit/blob/master/pkg/config/editor_presets.go).
+
+## Using aliases or functions in shell commands
+
+Lazygit has a command prompt (`:`) for quickly executing shell commands without having to quit lazygit or switch to a different terminal. Most people find it convenient to have their usual shell aliases or shell functions available at this prompt. To achieve this, put your alias definitions in a separate shell startup file (which you source from your normal startup file, i.e. from `.bashrc` or `.zshrc`), and then tell lazygit about this file like so:
+
+```yml
+os:
+ shellFunctionsFile: ~/.my_aliases.sh
+```
+
+For many people it might work well enough to use their entire shell config file (`~/.bashrc` or `~/.zshrc`) as the `shellFunctionsFile`, but these config files typically do a lot more than defining aliases (e.g. initialize the completion system, start an ssh-agent, etc.) and this may unnecessarily delay execution of shell commands.
+
+When using zsh, aliases can't be used here, but functions can. It is easy to convert your existing aliases into functions, just change `alias l="ls -la"` to `l() ls -la`, for example. This way it will work as before both in the shell and in lazygit.
+
+Note that the shell aliases file is not only used when executing shell commands, but also for [custom commands](Custom_Command_Keybindings.md), and when opening a file in the editor.
+
+## Overriding default config file location
+
+To override the default config directory, use `CONFIG_DIR="$HOME/.config/lazygit"`. This directory contains the config file in addition to some other files lazygit uses to keep track of state across sessions.
+
+To override the individual config file used, use the `--use-config-file` arg or the `LG_CONFIG_FILE` env var.
+
+If you want to merge a specific config file into a more general config file, perhaps for the sake of setting some theme-specific options, you can supply a list of comma-separated config file paths, like so:
+
+```sh
+lazygit --use-config-file="$HOME/.base_lg_conf,$HOME/.light_theme_lg_conf"
+or
+LG_CONFIG_FILE="$HOME/.base_lg_conf,$HOME/.light_theme_lg_conf" lazygit
+```
+
+## Scroll-off Margin
+
+When the selected line gets close to the bottom of the window and you hit down-arrow, there's a feature called "scroll-off margin" that lets the view scroll a little earlier so that you can see a bit of what's coming in the direction that you are moving. This is controlled by the `gui.scrollOffMargin` setting (default: 2), so it keeps 2 lines below the selection visible as you scroll down. It can be set to 0 to scroll only when the selection reaches the bottom of the window.
+
+That's the behavior when `gui.scrollOffBehavior` is set to "margin" (the default). If you set `gui.scrollOffBehavior` to "jump", then upon reaching the last line of a view and hitting down-arrow the view will scroll by half a page so that the selection ends up in the middle of the view. This may feel a little jarring because the cursor jumps around when continuously moving down, but it has the advantage that the view doesn't scroll as often.
+
+This setting applies both to all list views (e.g. commits and branches etc), and to the staging view.
+
+## Filtering
+
+We have two ways to filter things, substring matching (the default) and fuzzy searching. With substring matching, the text you enter gets searched for verbatim (usually case-insensitive, except when your filter string contains uppercase letters, in which case we search case-sensitively). You can search for multiple non-contiguous substrings by separating them with spaces; for example, "int test" will match "integration-testing". All substrings have to match, but not necessarily in the given order.
+
+Fuzzy searching is smarter in that it allows every letter of the filter string to match anywhere in the text (only in order though), assigning a weight to the quality of the match and sorting by that order. This has the advantage that it allows typing "clt" to match "commit_loader_test" (letters at the beginning of subwords get more weight); but it has the disadvantage that it tends to return lots of irrelevant results, especially with short filter strings.
+
+## Color Attributes
+
+For color attributes you can choose an array of attributes (with max one color attribute)
+The available attributes are:
+
+**Colors**
+
+- black
+- red
+- green
+- yellow
+- blue
+- magenta
+- cyan
+- white
+- '#ff00ff'
+
+**Modifiers**
+
+- bold
+- default
+- reverse # useful for high-contrast
+- underline
+- strikethrough
+
+## Highlighting the selected line
+
+If you don't like the default behaviour of highlighting the selected line with a blue background, you can use the `selectedLineBgColor` key to customise the behaviour. If you just want to embolden the selected line (this was the original default), you can do the following:
+
+```yaml
+gui:
+ theme:
+ selectedLineBgColor:
+ - default
+```
+
+You can also use the reverse attribute like so:
+
+```yaml
+gui:
+ theme:
+ selectedLineBgColor:
+ - reverse
+```
+
+## Custom Author Color
+
+Lazygit will assign a random color for every commit author in the commits pane by default.
+
+You can customize the color in case you're not happy with the randomly assigned one:
+
+```yaml
+gui:
+ authorColors:
+ 'John Smith': 'red' # use red for John Smith
+ 'Alan Smithee': '#00ff00' # use green for Alan Smithee
+```
+
+You can use wildcard to set a unified color in case your are lazy to customize the color for every author or you just want a single color for all/other authors:
+
+```yaml
+gui:
+ authorColors:
+ # use red for John Smith
+ 'John Smith': 'red'
+ # use blue for other authors
+ '*': '#0000ff'
+```
+
+## Custom Branch Color
+
+You can customize the color of branches based on branch patterns (regular expressions):
+
+```yaml
+gui:
+ branchColorPatterns:
+ '^docs/': '#11aaff' # use a light blue for branches beginning with 'docs/'
+ 'ISSUE-\d+': '#ff5733' # use a bright orange for branches containing 'ISSUE-'
+```
+
+Note that the regular expressions are not implicitly anchored to the beginning/end of the branch name. If you want to do that, add leading `^` and/or trailing `$` as needed.
+
+## Custom Files Icon & Color
+
+You can customize the icon and color of files based on filenames or extensions:
+
+```yaml
+gui:
+ customIcons:
+ filenames:
+ "CONTRIBUTING.md": { icon: "\uede2", color: "#FEDDEF" }
+ "HACKING.md": { icon: "\uede2", color: "#FEDDEF" }
+ extensions:
+ ".cat":
+ icon: "\U000f011b"
+ color: "#BC4009"
+ ".dog":
+ icon: "\U000f0a43"
+ color: "#B6977E"
+```
+
+Note that there is no support for regular expressions.
+
+## Example Coloring
+
+
+
+## Display Nerd Fonts Icons
+
+If you are using [Nerd Fonts](https://www.nerdfonts.com), you can display icons.
+
+```yaml
+gui:
+ nerdFontsVersion: "3"
+```
+
+Supported versions are "2" and "3". The deprecated config `showIcons` sets the version to "2" for backwards compatibility.
+
+## Keybindings
+
+For all possible keybinding options, check [Custom_Keybindings.md](keybindings/Custom_Keybindings.md)
+
+You can disable certain key bindings by specifying ``.
+
+```yaml
+keybinding:
+ universal:
+ edit: # disable 'edit file'
+```
+
+### Example Keybindings For Colemak Users
+
+```yaml
+keybinding:
+ universal:
+ prevItem-alt: 'u'
+ nextItem-alt: 'e'
+ prevBlock-alt: 'n'
+ nextBlock-alt: 'i'
+ nextMatch: '='
+ prevMatch: '-'
+ new: 'k'
+ edit: 'o'
+ openFile: 'O'
+ scrollUpMain-alt1: 'U'
+ scrollDownMain-alt1: 'E'
+ scrollUpMain-alt2: ''
+ scrollDownMain-alt2: ''
+ undo: 'l'
+ redo: ''
+ diffingMenu: 'M'
+ filteringMenu: ''
+ files:
+ ignoreFile: 'I'
+ commits:
+ moveDownCommit: ''
+ moveUpCommit: ''
+ branches:
+ viewGitFlowOptions: 'I'
+ setUpstream: 'U'
+```
+
+## Custom pull request URLs
+
+Some git provider setups (e.g. on-premises GitLab) can have distinct URLs for git-related calls and the web interface/API itself. To work with those, Lazygit needs to know where it needs to create the pull request. You can do so on your `config.yml` file using the following syntax:
+
+```yaml
+services:
+ '': ':'
+```
+
+Where:
+
+- `gitDomain` stands for the domain used by git itself (i.e. the one present on clone URLs), e.g. `git.work.com`
+- `provider` is one of `github`, `bitbucket`, `bitbucketServer`, `azuredevops`, `gitlab` or `gitea`
+- `webDomain` is the URL where your git service exposes a web interface and APIs, e.g. `gitservice.work.com`
+
+## Predefined commit message prefix
+
+In situations where certain naming pattern is used for branches and commits, pattern can be used to populate commit message with prefix that is parsed from the branch name.
+If you define multiple naming patterns, they will be attempted in order until one matches.
+
+Example hitting first match:
+
+- Branch name: feature/AB-123
+- Generated commit message prefix: [AB-123]
+
+Example hitting second match:
+
+- Branch name: CD-456_fix_problem
+- Generated commit message prefix: (CD-456)
+
+```yaml
+git:
+ commitPrefix:
+ - pattern: "^\\w+\\/(\\w+-\\w+).*"
+ replace: '[$1] '
+ - pattern: "^([^_]+)_.*" # Take all text prior to the first underscore
+ replace: '($1) '
+```
+
+If you want repository-specific prefixes, you can map them with `commitPrefixes`. If you have both entries in `commitPrefix` defined and an repository match in `commitPrefixes` for the current repo, the `commitPrefixes` entries will be attempted first. Repository folder names must be an exact match.
+
+```yaml
+git:
+ commitPrefixes:
+ my_project: # This is repository folder name
+ - pattern: "^\\w+\\/(\\w+-\\w+).*"
+ replace: '[$1] '
+ commitPrefix:
+ - pattern: "^(\\w+)-.*" # A more general match for any leading word
+ replace : '[$1] '
+ - pattern: ".*" # The final fallthrough regex that copies over the whole branch name
+ replace : '[$0] '
+```
+
+> [!IMPORTANT]
+> The way golang regex works is when you use `$n` in the replacement string, where `n` is a number, it puts the nth captured subgroup at that place. If `n` is out of range because there aren't that many capture groups in the regex, it puts an empty string there.
+>
+> So make sure you are capturing group or groups in your regex.
+>
+> For example `^[A-Z]+-\d+$` won't work on branch name like BRANCH-1111
+> But `^([A-Z]+-\d+)$` will
+
+## Predefined branch name prefix
+
+In situations where certain naming pattern is used for branches, this can be used to populate new branch creation with a static prefix.
+
+Example:
+
+Some branches:
+
+- jsmith/AB-123
+- cwilson/AB-125
+
+```yaml
+git:
+ branchPrefix: "firstlast/"
+```
+
+It's possible to use a dynamic prefix by using the `runCommand` function:
+
+```yaml
+git:
+ branchPrefix: "firstlast/{{ runCommand "date +\"%Y/%-m\"" }}/"
+```
+
+This would produce something like: `firstlast/2025/4/`
+
+## Custom git log command
+
+You can override the `git log` command that's used to render the log of the selected branch like so:
+
+```
+git:
+ branchLogCmd: "git log --graph --color=always --abbrev-commit --decorate --date=relative --pretty=medium --oneline {{branchName}} --"
+```
+
+Result:
+
+
+
+## Launching not in a repository behaviour
+
+By default, when launching lazygit from a directory that is not a repository, you will be prompted to choose if you would like to initialize a repo. You can override this behaviour in the config with one of the following:
+
+```yaml
+# for default prompting behaviour
+notARepository: 'prompt'
+```
+
+```yaml
+# to skip and initialize a new repo
+notARepository: 'create'
+```
+
+```yaml
+# to skip without creating a new repo
+notARepository: 'skip'
+```
+
+```yaml
+# to exit immediately if run outside of the Git repository
+notARepository: 'quit'
+```
diff --git a/docs-master/Custom_Command_Keybindings.md b/docs-master/Custom_Command_Keybindings.md
new file mode 100644
index 000000000..cdc4046b7
--- /dev/null
+++ b/docs-master/Custom_Command_Keybindings.md
@@ -0,0 +1,372 @@
+# Custom Command Keybindings
+
+You can add custom command keybindings in your config.yml (accessible by pressing 'e' on the status panel from within lazygit) like so:
+
+```yml
+customCommands:
+ - key: ''
+ context: 'commits'
+ command: 'hub browse -- "commit/{{.SelectedLocalCommit.Hash}}"'
+ - key: 'a'
+ context: 'files'
+ command: "git {{if .SelectedFile.HasUnstagedChanges}} add {{else}} reset {{end}} {{.SelectedFile.Name | quote}}"
+ description: 'Toggle file staged'
+ - key: 'C'
+ context: 'global'
+ command: "git commit"
+ output: terminal
+ - key: 'n'
+ context: 'localBranches'
+ prompts:
+ - type: 'menu'
+ title: 'What kind of branch is it?'
+ key: 'BranchType'
+ options:
+ - name: 'feature'
+ description: 'a feature branch'
+ value: 'feature'
+ - name: 'hotfix'
+ description: 'a hotfix branch'
+ value: 'hotfix'
+ - name: 'release'
+ description: 'a release branch'
+ value: 'release'
+ - type: 'input'
+ title: 'What is the new branch name?'
+ key: 'BranchName'
+ initialValue: ''
+ command: "git flow {{.Form.BranchType}} start {{.Form.BranchName}}"
+ loadingText: 'Creating branch'
+```
+
+Looking at the command assigned to the 'n' key, here's what the result looks like:
+
+
+
+Custom command keybindings will appear alongside inbuilt keybindings when you view the keybindings menu by pressing '?':
+
+
+
+For a given custom command, here are the allowed fields:
+| _field_ | _description_ | required |
+|-----------------|----------------------|-|
+| key | The key to trigger the command. Use a single letter or one of the values from [here](https://github.com/jesseduffield/lazygit/blob/master/docs/keybindings/Custom_Keybindings.md). Custom commands without a key specified can be triggered by selecting them from the keybindings (`?`) menu | no |
+| command | The command to run (using Go template syntax for placeholder values) | yes |
+| context | The context in which to listen for the key (see [below](#contexts)) | yes |
+| prompts | A list of prompts that will request user input before running the final command | no |
+| loadingText | Text to display while waiting for command to finish | no |
+| description | Label for the custom command when displayed in the keybindings menu | no |
+| output | Where the output of the command should go. 'none' discards it, 'terminal' suspends lazygit and runs the command in the terminal (useful for commands that require user input), 'log' streams it to the command log, 'logWithPty' is like 'log' but runs the command in a pseudo terminal (can be useful for commands that produce colored output when the output is a terminal), and 'popup' shows it in a popup. | no |
+| outputTitle | The title to display in the popup panel if output is set to 'popup'. If left unset, the command will be used as the title. | no |
+| after | Actions to take after the command has completed | no |
+
+Here are the options for the `after` key:
+| _field_ | _description_ | required |
+|-----------------|----------------------|-|
+| checkForConflicts | true/false. If true, check for merge conflicts | no |
+
+## Contexts
+
+The permitted contexts are:
+
+| _context_ | _description_ |
+| -------------- | -------------------------------------------------------------------------------------------------------- |
+| status | The 'Status' tab |
+| files | The 'Files' tab |
+| worktrees | The 'Worktrees' tab |
+| submodules | The 'Submodules' tab |
+| localBranches | The 'Local Branches' tab |
+| remotes | The 'Remotes' tab |
+| remoteBranches | The context you get when pressing enter on a remote in the remotes tab |
+| tags | The 'Tags' tab |
+| commits | The 'Commits' tab |
+| reflogCommits | The 'Reflog' tab |
+| subCommits | The context you see when pressing enter on a branch |
+| commitFiles | The context you see when pressing enter on a commit or stash entry (warning, might be renamed in future) |
+| stash | The 'Stash' tab |
+| global | This keybinding will take affect everywhere |
+
+> **Bonus**
+>
+> You can use a comma-separated string, such as `context: 'commits, subCommits'`, to make it effective in multiple contexts.
+
+
+## Prompts
+
+### Common fields
+
+These fields are applicable to all prompts.
+
+| _field_ | _description_ | _required_ |
+| ------------ | -----------------------------------------------------------------------------------------------| ---------- |
+| type | One of 'input', 'confirm', 'menu', 'menuFromCommand' | yes |
+| title | The title to display in the popup panel | no |
+| key | Used to reference the entered value from within the custom command. E.g. a prompt with `key: 'Branch'` can be referred to as `{{.Form.Branch}}` in the command | yes |
+
+### Input
+
+| _field_ | _description_ | _required_ |
+| ------------ | -----------------------------------------------------------------------------------------------| ---------- |
+| initialValue | The initial value to appear in the text box | no |
+| suggestions | Shows suggestions as the input is entered. See below for details | no |
+
+The permitted suggestions fields are:
+| _field_ | _description_ | _required_ |
+|-----------------|----------------------|-|
+| preset | Uses built-in logic to obtain the suggestions. One of 'authors', 'branches', 'files', 'refs', 'remotes', 'remoteBranches', 'tags' | no |
+| command | Command to run such that each line in the output becomes a suggestion. Mutually exclusive with 'preset' field. | no |
+
+Here's an example of passing a preset:
+
+```yml
+customCommands:
+ - key: 'a'
+ command: 'echo {{.Form.Branch | quote}}'
+ context: 'commits'
+ prompts:
+ - type: 'input'
+ title: 'Which branch?'
+ key: 'Branch'
+ suggestions:
+ preset: 'branches' # use built-in logic for obtaining branches
+```
+
+Here's an example of passing a command directly:
+
+```yml
+customCommands:
+ - key: 'a'
+ command: 'echo {{.Form.Branch | quote}}'
+ context: 'commits'
+ prompts:
+ - type: 'input'
+ title: 'Which branch?'
+ key: 'Branch'
+ suggestions:
+ command: "git branch --format='%(refname:short)'"
+```
+
+
+Here's an example of passing an initial value for the input:
+
+```yml
+customCommands:
+ - key: 'a'
+ command: 'echo {{.Form.Remote | quote}}'
+ context: 'commits'
+ prompts:
+ - type: 'input'
+ title: 'Remote:'
+ key: 'Remote'
+ initialValue: "{{.SelectedRemote.Name}}"
+```
+
+### Confirm
+
+| _field_ | _description_ | _required_ |
+| ------------ | -----------------------------------------------------------------------------------------------| ---------- |
+| body | The immutable body text to appear in the text box | no |
+
+Example:
+
+```yml
+customCommands:
+ - key: 'a'
+ command: 'echo "pushing to remote"'
+ context: 'commits'
+ prompts:
+ - type: 'confirm'
+ title: 'Push to remote'
+ body: 'Are you sure you want to push to the remote?'
+```
+
+### Menu
+
+| _field_ | _description_ | _required_ |
+| ------------ | -----------------------------------------------------------------------------------------------| ---------- |
+| options | The options to display in the menu | yes |
+
+The permitted option fields are:
+| _field_ | _description_ | _required_ |
+|-----------------|----------------------|-|
+| name | The first part of the label | no |
+| description | The second part of the label | no |
+| value | the value that will be used in the command | yes |
+
+If an option has no name the value will be displayed to the user in place of the name, so you're allowed to only include the value like so:
+
+```yml
+customCommands:
+ - key: 'a'
+ command: 'echo {{.Form.BranchType | quote}}'
+ context: 'commits'
+ prompts:
+ - type: 'menu'
+ title: 'What kind of branch is it?'
+ key: 'BranchType'
+ options:
+ - value: 'feature'
+ - value: 'hotfix'
+ - value: 'release'
+```
+
+Here's an example of supplying more detail for each option:
+
+```yml
+customCommands:
+ - key: 'a'
+ command: 'echo {{.Form.BranchType | quote}}'
+ context: 'commits'
+ prompts:
+ - type: 'menu'
+ title: 'What kind of branch is it?'
+ key: 'BranchType'
+ options:
+ - value: 'feature'
+ name: 'feature branch'
+ description: 'branch based off develop'
+ - value: 'hotfix'
+ name: 'hotfix branch'
+ description: 'branch based off main for fast bug fixes'
+ - value: 'release'
+ name: 'release branch'
+ description: 'branch for a release'
+```
+
+### Menu-from-command
+
+| _field_ | _description_ | _required_ |
+| ------------ | -----------------------------------------------------------------------------------------------| ---------- |
+| command | The command to run to generate menu options | yes |
+| filter | The regexp to run specifying groups which are going to be kept from the command's output | no |
+| valueFormat | How to format matched groups from the filter to construct a menu item's value | no |
+| labelFormat | Like valueFormat but for the labels. If `labelFormat` is not specified, `valueFormat` is shown instead. | no |
+
+Here's an example using named groups in the regex. Notice how we can pipe the label to a colour function for coloured output (available colours [here](https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md))
+
+```yml
+ - key : 'a'
+ description: 'Checkout a remote branch as FETCH_HEAD'
+ command: "git fetch {{.Form.Remote}} {{.Form.Branch}} && git checkout FETCH_HEAD"
+ context: 'remotes'
+ prompts:
+ - type: 'menuFromCommand'
+ title: 'Remote branch:'
+ key: 'Branch'
+ command: 'git branch -r --list {{.SelectedRemote.Name }}/*'
+ filter: '.*{{.SelectedRemote.Name }}/(?P.*)'
+ valueFormat: '{{ .branch }}'
+ labelFormat: '{{ .branch | green }}'
+```
+
+Here's an example using unnamed groups:
+
+```yml
+ - key : 'a'
+ description: 'Checkout a remote branch as FETCH_HEAD'
+ command: "git fetch {{.Form.Remote}} {{.Form.Branch}} && git checkout FETCH_HEAD"
+ context: 'remotes'
+ prompts:
+ - type: 'menuFromCommand'
+ title: 'Remote branch:'
+ key: 'Branch'
+ command: 'git branch -r --list {{.SelectedRemote.Name }}/*'
+ filter: '.*{{.SelectedRemote.Name }}/(.*)'
+ valueFormat: '{{ .group_1 }}'
+ labelFormat: '{{ .group_1 | green }}'
+```
+
+Here's an example using a command but not specifying anything else: so each line from the command becomes the value and label of the menu items
+
+```yml
+ - key : 'a'
+ description: 'Checkout a remote branch as FETCH_HEAD'
+ command: "open {{.Form.File | quote}}"
+ context: 'global'
+ prompts:
+ - type: 'menuFromCommand'
+ title: 'File:'
+ key: 'File'
+ command: 'ls'
+```
+
+## Placeholder values
+
+Your commands can contain placeholder strings using Go's [template syntax](https://jan.newmarch.name/golang/template/chapter-template.html). The template syntax is pretty powerful, letting you do things like conditionals if you want, but for the most part you'll simply want to be accessing the fields on the following objects:
+
+```
+SelectedCommit
+SelectedCommitRange
+SelectedFile
+SelectedPath
+SelectedSubmodule
+SelectedLocalBranch
+SelectedRemoteBranch
+SelectedRemote
+SelectedTag
+SelectedStashEntry
+SelectedCommitFile
+SelectedWorktree
+CheckedOutBranch
+```
+
+(For legacy reasons, `SelectedLocalCommit`, `SelectedReflogCommit`, and `SelectedSubCommit` are also available, but they are deprecated.)
+
+
+To see what fields are available on e.g. the `SelectedFile`, see [here](https://github.com/jesseduffield/lazygit/blob/master/pkg/gui/services/custom_commands/models.go) (all the modelling lives in the same file).
+
+We don't support accessing all elements of a range selection yet. We might add this in the future, but as a special case you can access the range of selected commits by using `SelectedCommitRange`, which has two properties `.To` and `.From` which are the hashes of the bottom and top selected commits, respectively. This is useful for passing them to a git command that operates on a range of commits. For example, to create patches for all selected commits, you might use
+```yml
+ command: "git format-patch {{.SelectedCommitRange.From}}^..{{.SelectedCommitRange.To}}"
+```
+
+We support the following functions:
+
+### Quoting
+
+Quote wraps a string in quotes with necessary escaping for the current platform.
+
+```
+git {{.SelectedFile.Name | quote}}
+```
+
+### Running a command
+
+Runs a command and returns the output. If the command outputs more than a single line, it will produce an error.
+
+```
+initialValue: "username/{{ runCommand "date +\"%Y/%-m\"" }}/"
+```
+
+## Keybinding collisions
+
+If your custom keybinding collides with an inbuilt keybinding that is defined for the same context, only the custom keybinding will be executed. This also applies to the global context. However, one caveat is that if you have a custom keybinding defined on the global context for some key, and there is an in-built keybinding defined for the same key and for a specific context (say the 'files' context), then the in-built keybinding will take precedence. See how to change in-built keybindings [here](https://github.com/jesseduffield/lazygit/blob/master/docs/Config.md#keybindings)
+
+## Menus of custom commands
+
+For custom commands that are not used very frequently it may be preferable to hide them in a menu; you can assign a key to open the menu, and the commands will appear inside. This has the advantage that you don't have to come up with individual unique keybindings for all those commands that you don't use often; the keybindings for the commands in the menu only need to be unique within the menu. Here is an example:
+
+```yml
+customCommands:
+- key: X
+ description: "Copy/paste commits across repos"
+ commandMenu:
+ - key: c
+ command: 'git format-patch --stdout {{.SelectedCommitRange.From}}^..{{.SelectedCommitRange.To}} | pbcopy'
+ context: commits, subCommits
+ description: "Copy selected commits to clipboard"
+ - key: v
+ command: 'pbpaste | git am'
+ context: "commits"
+ description: "Paste selected commits from clipboard"
+```
+
+If you use the commandMenu property, none of the other properties except key and description can be used.
+
+## Debugging
+
+If you want to verify that your command actually does what you expect, you can wrap it in an 'echo' call and set `output: popup` so that it doesn't actually execute the command but you can see how the placeholders were resolved.
+
+## More Examples
+
+See the [wiki](https://github.com/jesseduffield/lazygit/wiki/Custom-Commands-Compendium) page for more examples, and feel free to add your own custom commands to this page so others can benefit!
diff --git a/docs-master/Custom_Pagers.md b/docs-master/Custom_Pagers.md
new file mode 100644
index 000000000..c6616cecf
--- /dev/null
+++ b/docs-master/Custom_Pagers.md
@@ -0,0 +1,116 @@
+# Custom Pagers
+
+Lazygit supports custom pagers, [configured](/docs/Config.md) in the config.yml file (which can be opened by pressing `e` in the Status panel).
+
+Support does not extend to Windows users, because we're making use of a package which doesn't have Windows support. However, see [below](#emulating-custom-pagers-on-windows) for a workaround.
+
+Multiple pagers are supported; you can cycle through them with the `|` key. This can be useful if you usually prefer a particular pager, but want to use a different one for certain kinds of diffs.
+
+Pagers are configured with the `pagers` array in the git section; here's an example for a multi-pager setup:
+
+```yaml
+git:
+ pagers:
+ - pager: delta --dark --paging=never
+ - pager: ydiff -p cat -s --wrap --width={{columnWidth}}
+ colorArg: never
+ - externalDiffCommand: difft --color=always
+```
+
+The `colorArg` key is for whether you want the `--color=always` arg in your `git diff` command. Some pagers want it set to `always`, others want it set to `never`. The default is `always`, since that's what most pagers need.
+
+## Delta:
+
+```yaml
+git:
+ pagers:
+ - pager: delta --dark --paging=never
+```
+
+
+
+A cool feature of delta is --hyperlinks, which renders clickable links for the line numbers in the left margin, and lazygit supports these. To use them, set the `pager:` config to `delta --dark --paging=never --line-numbers --hyperlinks --hyperlinks-file-link-format="lazygit-edit://{path}:{line}"`; this allows you to click on an underlined line number in the diff to jump right to that same line in your editor.
+
+## Diff-so-fancy
+
+```yaml
+git:
+ pagers:
+ - pager: diff-so-fancy
+```
+
+
+
+## ydiff
+
+```yaml
+gui:
+ sidePanelWidth: 0.2 # gives you more space to show things side-by-side
+git:
+ pagers:
+ - colorArg: never
+ pager: ydiff -p cat -s --wrap --width={{columnWidth}}
+```
+
+
+
+Be careful with this one, I think the homebrew and pip versions are behind master. I needed to directly download the ydiff script to get the no-pager functionality working.
+
+## Using external diff commands
+
+Some diff tools can't work as a simple pager like the ones above do, because they need access to the entire diff, so just post-processing git's diff is not enough for them. The most notable example is probably [difftastic](https://difftastic.wilfred.me.uk).
+
+These can be used in lazygit by using the `externalDiffCommand` config; in the case of difftastic, that could be
+
+```yaml
+git:
+ pagers:
+ - externalDiffCommand: difft --color=always
+```
+
+The `colorArg` and `pager` options are not used in this case.
+
+You can add whatever extra arguments you prefer for your difftool; for instance
+
+```yaml
+git:
+ pagers:
+ - externalDiffCommand: difft --color=always --display=inline --syntax-highlight=off
+```
+
+Instead of setting this command in lazygit's `externalDiffCommand` config, you can also tell lazygit to use the external diff command that is configured in git itself (`diff.external`), by using
+
+```yaml
+git:
+ pagers:
+ - useExternalDiffGitConfig: true
+```
+
+This can be useful if you also want to use it for diffs on the command line, and it also has the advantage that you can configure it per file type in `.gitattributes`; see https://git-scm.com/docs/gitattributes#_defining_an_external_diff_driver.
+
+## Emulating custom pagers on Windows
+
+There is a trick to emulate custom pagers on Windows using a Powershell script configured as an external diff command. It's not perfect, but certainly better than nothing. To do this, save the following script as `lazygit-pager.ps1` at a convenient place on your disk:
+
+```pwsh
+#!/usr/bin/env pwsh
+
+$old = $args[1].Replace('\', '/')
+$new = $args[4].Replace('\', '/')
+$path = $args[0]
+git diff --no-index --no-ext-diff $old $new
+ | %{ $_.Replace($old, $path).Replace($new, $path) }
+ | delta --width=$env:LAZYGIT_COLUMNS
+```
+
+Use the pager of your choice with the arguments you like in the last line of the script. Personally I wouldn't want to use lazygit anymore without delta's `--hyperlinks --hyperlinks-file-link-format="lazygit-edit://{path}:{line}"` args, see [above](#delta).
+
+In your lazygit config, use
+
+```yml
+git:
+ pagers:
+ - externalDiffCommand: "C:/wherever/lazygit-pager.ps1"
+```
+
+The main limitation of this approach compared to a "real" pager is that renames are not displayed correctly; they are shown as if they were modifications of the old file. (This affects only the hunk headers; the diff itself is always correct.)
diff --git a/docs-master/Fixup_Commits.md b/docs-master/Fixup_Commits.md
new file mode 100644
index 000000000..d08914f33
--- /dev/null
+++ b/docs-master/Fixup_Commits.md
@@ -0,0 +1,65 @@
+# Fixup Commits
+
+## Background
+
+There's this common scenario that you have a PR in review, the reviewer is
+requesting some changes, and you make those changes and would normally simply
+squash them into the original commit that they came from. If you do that,
+however, there's no way for the reviewer to see what you changed. You could just
+make a separate commit with those changes at the end of the branch, but this is
+not ideal because it results in a git history that is not very clean.
+
+To help with this, git has a concept of fixup commits: you do make a separate
+commit, but the subject of this commit is the string "fixup! " followed by the
+original commit subject. This both tells the reviewer what's going on (you are
+making a change that you later will squash into the designated commit), and it
+provides an easy way to actually perform this squash operation when you are
+ready to do that (before merging).
+
+## Creating fixup commits
+
+You could of course create fixup commits manually by typing in the commit
+message with the prefix yourself. But lazygit has an easier way to do that:
+in the Commits view, select the commit that you want to create a fixup for, and
+press shift-F (for "Create fixup commit for this commit"). This automatically
+creates a commit with the appropriate subject line.
+
+Don't confuse this with the lowercase "f" command ("Fixup commit"); that one
+squashes the selected commit into its parent, this is not what we want here.
+
+## Creating amend commits
+
+There's a special type of fixup commit that uses "amend!" instead of "fixup!" in
+the commit message subject; in addition to fixing up the original commit with
+changes it allows you to also (or only) change the commit message of the
+original commit. The menu that appears when pressing shift-F has options for
+both of these; they bring up a commit message panel similar to when you reword a
+commit, but then create the "amend!" commit containing the new message. Note
+that in that panel you only type the new message as you want it to be
+eventually; lazygit then takes care of formatting the "amend!" commit
+appropriately for you (with the subject of your new message moving into the body
+of the "amend!" commit).
+
+## Squashing fixup commits
+
+When you're ready to merge the branch and want to squash all these fixup commits
+that you created, that's very easy to do: select the first commit of your branch
+and hit shift-S (for "Squash all 'fixup!' commits above selected commit
+(autosquash)"). Boom, done.
+
+## Finding the commit to create a fixup for
+
+When you are making changes to code that you changed earlier in a long branch,
+it can be tedious to find the commit to squash it into. Lazygit has a command to
+help you with this, too: in the Files view, press ctrl-f to select the right
+base commit in the Commits view automatically. From there, you can either press
+shift-F to create a fixup commit for it, or shift-A to amend your changes into
+the commit if you haven't published your branch yet.
+
+If you have many modifications in your working copy, it is a good idea to stage
+related changes that are meant to go into the same fixup commit; if no changes
+are staged, ctrl-f works on all unstaged modifications, and then it might show
+an error if it finds multiple different base commits. If you are interested in
+what the command does to do its magic, and how you can help it work better, you
+may want to read the [design document](dev/Find_Base_Commit_For_Fixup_Design.md)
+that describes this.
diff --git a/docs-master/README.md b/docs-master/README.md
new file mode 100644
index 000000000..1bc0bb6be
--- /dev/null
+++ b/docs-master/README.md
@@ -0,0 +1,11 @@
+# Documentation Overview
+
+* [Configuration](./Config.md).
+* [Custom Commands](./Custom_Command_Keybindings.md)
+* [Custom Pagers](./Custom_Pagers.md)
+* [Dev docs](./dev)
+* [Keybindings](./keybindings)
+* [Undo/Redo](./Undoing.md)
+* [Range Select](./Range_Select.md)
+* [Searching/Filtering](./Searching.md)
+* [Stacked Branches](./Stacked_Branches.md)
diff --git a/docs-master/Range_Select.md b/docs-master/Range_Select.md
new file mode 100644
index 000000000..e46c26897
--- /dev/null
+++ b/docs-master/Range_Select.md
@@ -0,0 +1,14 @@
+# Range Select
+
+Some actions can be performed on a range of contiguous items. For example:
+* staging multiple files at once
+* squashing multiple commits at once
+* copying (for cherry-pick) multiple commits at once
+
+There are two ways to select a range of items:
+1. Sticky range select: Press 'v' to toggle range select, then expand the selection using the up/down arrow key. To reset the selection, press 'v' again.
+2. Non-sticky range select: Press shift+up or shift+down to expand the selection. To reset the selection, press up/down without shift.
+
+The sticky option will be more familiar to vim users, and the second option will feel more natural to users who aren't used to doing things in a modal way.
+
+In order to perform an action on a range of items, simply press the normal key for that action. If the action only works on individual items, it will raise an error. This is a new feature and the plan is to incrementally support range select for more and more actions. If there is an action you would like to support range select which currently does not, please raise an issue in the repo.
diff --git a/docs-master/Searching.md b/docs-master/Searching.md
new file mode 100644
index 000000000..589831c55
--- /dev/null
+++ b/docs-master/Searching.md
@@ -0,0 +1,21 @@
+# Searching/Filtering
+
+## View searching/filtering
+
+Depending on the currently focused view, hitting '/' will bring up a filter or search prompt. When filtering, the contents of the view will be filtered down to only those lines which match the query string. When searching, the contents of the view are not filtered, but matching lines are highlighted and you can iterate through matches with `n`/`N`.
+
+We intend to support filtering for the files view soon, but at the moment it uses searching. We intend to continue using search for the commits view because you typically care about the commits that come before/after a matching commit.
+
+If you would like both filtering and searching to be enabled on a given view, please raise an issue for this.
+
+## Filtering files by status
+
+You can filter the files view to only show staged/unstaged files by pressing `` in the files view.
+
+## Filtering commits by file path
+
+You can filter the commits view to only show commits which contain changes to a given file path.
+
+You can do this in a couple of ways:
+1) Start lazygit with the -f flag e.g. `lazygit -f my/path`
+2) From within lazygit, press `` and then enter the path of the file you want to filter by
diff --git a/docs-master/Stacked_Branches.md b/docs-master/Stacked_Branches.md
new file mode 100644
index 000000000..cd573be26
--- /dev/null
+++ b/docs-master/Stacked_Branches.md
@@ -0,0 +1,18 @@
+# Working with stacked branches
+
+When working on a large branch it can often be useful to break it down into
+smaller pieces, and it can help to create separate branches for each independent
+chunk of changes. For example, you could have one branch for preparatory
+refactorings, one for backend changes, and one for frontend changes. Those
+branches would then all be stacked onto each other.
+
+Git has support for rebasing such a stack as a whole; you can enable it by
+setting the git config `rebase.updateRefs` to true. If you then rebase the
+topmost branch of the stack, the other ones in the stack will follow. This
+includes interactive rebases, so for example amending a commit in the first
+branch of the stack will "just work" in the sense that it keeps the other
+branches properly stacked onto it.
+
+Lazygit visualizes the individual branch heads in the stack by marking them with a
+cyan asterisk (or a cyan branch symbol if you are using [nerd
+fonts](Config.md#display-nerd-fonts-icons)).
diff --git a/docs-master/Undoing.md b/docs-master/Undoing.md
new file mode 100644
index 000000000..0a4c2f381
--- /dev/null
+++ b/docs-master/Undoing.md
@@ -0,0 +1,24 @@
+# Undo/Redo in lazygit
+
+You can undo the last action by pressing 'z' and redo with `ctrl+z`. Here we drop a couple of commits and then undo the actions.
+Undo uses the reflog which is specific to commits and branches so we can't undo changes to the working tree or stash.
+
+
+
+## How it works
+
+If you're as clumsy as me you'll probably have felt the pain of botching an interactive rebase or doing a hard reset onto the wrong commit. Luckily, the reflog allows you to trace your steps and make things right again, but I personally can't stand trying to make sense of the reflog.
+
+Lazygit can read through your reflog for you and walk back action by action so that you don't even need to read the reflog. If lazygit finds a reflog entry where you checked out a branch, we'll checkout the original branch. If the entry is from a commit being applied, we'll go back to the commit before that. If we hit an interactive rebase, we'll go back to the commit you were on just before you started it.
+
+## You can even undo things you did outside of lazygit!
+
+Because lazygit just uses the reflog to keep track of things, it doesn't matter whether you're trying to undo something you did in lazygit or directly on the command line. You can open lazygit for the first time and start undoing thing in your repo! Likewise, lazygit marks its undos/redos in the reflog so if you quit the application and come back, lazygit still knows where you're up to.
+
+## Limitations
+
+There are limitations: firstly, lazygit can only undo things that are recorded in the reflog. That means changes to your working tree or stash aren't covered. Secondly, anything permanent you do like pushing to a remote can't be undone. Thirdly, actions like creating a branch won't be undone, because they're not stored in the reflog.
+
+If you are mid-rebase, undo/redo is not supported, because the reflog doesn't contain enough information about what specific things have happened inside that rebase. If you want to undo out of a rebase, it's best to abort the rebase (the default keybinding for bringing up rebase options is 'm').
+
+Undo/Redo is a new feature so if you find a bug let us know. The worst case scenario is that you'll just need to look at your reflog and manually put yourself back on track.
diff --git a/docs-master/dev/Busy.md b/docs-master/dev/Busy.md
new file mode 100644
index 000000000..6aa3b7bb5
--- /dev/null
+++ b/docs-master/dev/Busy.md
@@ -0,0 +1,78 @@
+# Knowing when Lazygit is busy/idle
+
+## The use-case
+
+This topic deserves its own doc because there are a few touch points for it. We have a use-case for knowing when Lazygit is idle or busy because integration tests follow the following process:
+1) press a key
+2) wait until Lazygit is idle
+3) run assertion / press another key
+4) repeat
+
+In the past the process was:
+1) press a key
+2) run assertion
+3) if assertion fails, wait a bit and retry
+4) repeat
+
+The old process was problematic because an assertion may give a false positive due to the contents of some view not yet having changed since the last key was pressed.
+
+## The solution
+
+First, it's important to distinguish three different types of goroutines:
+* The UI goroutine, of which there is only one, which infinitely processes a queue of events
+* Worker goroutines, which do some work and then typically enqueue an event in the UI goroutine to display the results
+* Background goroutines, which periodically spawn worker goroutines (e.g. doing a git fetch every minute)
+
+The point of distinguishing worker goroutines from background goroutines is that when any worker goroutine is running, we consider Lazygit to be 'busy', whereas this is not the case with background goroutines. It would be pointless to have background goroutines be considered 'busy' because then Lazygit would be considered busy for the entire duration of the program!
+
+In gocui, the underlying package we use for managing the UI and events, we keep track of how many busy goroutines there are using the `Task` type. A task represents some work being done by lazygit. The gocui Gui struct holds a map of tasks and allows creating a new task (which adds it to the map), pausing/continuing a task, and marking a task as done (which removes it from the map). Lazygit is considered to be busy so long as there is at least one busy task in the map; otherwise it's considered idle. When Lazygit goes from busy to idle, it notifies the integration test.
+
+It's important that we play by the rules below to ensure that after the user does anything, all the processing that follows happens in a contiguous block of busy-ness with no gaps.
+
+### Spawning a worker goroutine
+
+Here's the basic implementation of `OnWorker` (using the same flow as `WaitGroup`s):
+
+```go
+func (g *Gui) OnWorker(f func(*Task)) {
+ task := g.NewTask()
+ go func() {
+ f(task)
+ task.Done()
+ }()
+}
+```
+
+The crucial thing here is that we create the task _before_ spawning the goroutine, because it means that we'll have at least one busy task in the map until the completion of the goroutine. If we created the task within the goroutine, the current function could exit and Lazygit would be considered idle before the goroutine starts, leading to our integration test prematurely progressing.
+
+You typically invoke this with `self.c.OnWorker(f)`. Note that the callback function receives the task. This allows the callback to pause/continue the task (see below).
+
+### Spawning a background goroutine
+
+Spawning a background goroutine is as simple as:
+
+```go
+go utils.Safe(f)
+```
+
+Where `utils.Safe` is a helper function that ensures we clean up the gui if the goroutine panics.
+
+### Programmatically enqueueing a UI event
+
+This is invoked with `self.c.OnUIThread(f)`. Internally, it creates a task before enqueuing the function as an event (including the task in the event struct) and once that event is processed by the event queue (and any other pending events are processed) the task is removed from the map by calling `task.Done()`.
+
+### Pressing a key
+
+If the user presses a key, an event will be enqueued automatically and a task will be created before (and `Done`'d after) the event is processed.
+
+## Special cases
+
+There are a couple of special cases where we manually pause/continue the task directly in the client code. These are subject to change but for the sake of completeness:
+
+### Writing to the main view(s)
+
+If the user focuses a file in the files panel, we run a `git diff` command for that file and write the output to the main view. But we only read enough of the command's output to fill the view's viewport: further loading only happens if the user scrolls. Given that we have a background goroutine for running the command and writing more output upon scrolling, we create our own task and call `Done` on it as soon as the viewport is filled.
+
+### Requesting credentials from a git command
+
+Some git commands (e.g. git push) may request credentials. This is the same deal as above; we use a worker goroutine and manually pause continue its task as we go from waiting on the git command to waiting on user input. This requires passing the task through to the `Push` method so that it can be paused/continued.
diff --git a/docs-master/dev/Codebase_Guide.md b/docs-master/dev/Codebase_Guide.md
new file mode 100644
index 000000000..1692be33e
--- /dev/null
+++ b/docs-master/dev/Codebase_Guide.md
@@ -0,0 +1,100 @@
+# Lazygit Codebase Guide
+
+## Packages
+
+* `pkg/app`: Contains startup code, initialises a bunch of stuff like logging, the user config, etc, before starting the gui. Catches and handles some errors that the gui raises.
+* `pkg/app/daemon`: Contains code relating to the lazygit daemon. This could be better named: it's is not a daemon in the sense that it's a long-running background process; rather it's a short-lived background process that we pass to git for certain tasks, like GIT_EDITOR for when we want to set the TODO file for an interactive rebase.
+* `pkg/cheatsheet`: Generates the keybinding cheatsheets in `docs/keybindings`.
+* `pkg/commands/git_commands`: All communication to the git binary happens here. So for example there's a `Checkout` method which calls `git checkout`.
+* `pkg/commands/oscommands`: Contains code for talking to the OS, and for invoking commands in general
+* `pkg/commands/git_config`: Reading of the git config all happens here.
+* `pkg/commands/hosting_service`: Contains code that is specific to git hosting services (aka forges).
+* `pkg/commands/models`: Contains model structs that represent commits, branches, files, etc.
+* `pkg/commands/patch`: Contains code for parsing and working with git patches
+* `pkg/common`: Contains the `Common` struct which holds common dependencies like the logger, i18n, and the user config. Most structs in the code will have a field named `c` which holds a common struct (or a derivative of the common struct).
+* `pkg/config`: Contains code relating to the Lazygit user config. Specifically `pkg/config/user_config/go` defines the user config struct and its default values. See [below](#using-userconfig) for some important information about using it.
+* `pkg/constants`: Contains some constant strings (e.g. links to docs)
+* `pkg/env`: Contains code relating to setting/getting environment variables
+* `pkg/i18n`: Contains internationalised strings
+* `pkg/integration`: Contains end-to-end tests
+* `pkg/jsonschema`: Contains generator for user config JSON schema.
+* `pkg/logs`: Contains code for instantiating the logger and for tailing the logs via `lazygit --logs`
+* `pkg/tasks`: Contains code for running asynchronous tasks: mostly related to efficiently rendering command output to the main window.
+* `pkg/theme`: Contains code related to colour themes.
+* `pkg/updates`: Contains code related to Lazygit updates (checking for update, download and installing the update)
+* `pkg/utils`: Contains lots of low-level helper functions
+* `pkg/gui`: Contains code related to the gui. We've still got a God Struct in the form of our Gui struct, but over time code has been moved out into contexts, controllers, and helpers, and we intend to continue moving more code out over time.
+* `pkg/gui/context`: Contains code relating to contexts. There is a context for each view e.g. a branches context, a tags context, etc. Contexts manage state related to the view and receive keypresses.
+* `pkg/gui/controllers`: Contains code relating to controllers. Controllers define a list of keybindings and their associated handlers. One controller can be assigned to multiple contexts, and one context can contain multiple controllers.
+* `pkg/gui/controllers/helpers`: Contains code that is shared between multiple controllers.
+* `pkg/gui/filetree`: Contains code relating to the representation of filetrees.
+* `pkg/gui/keybindings`: Contains code for mapping between keybindings and their labels
+* `pkg/gui/mergeconflicts`: Contains code relating to the handling of merge conflicts
+* `pkg/gui/modes`: Contains code relating to the state of different modes e.g. cherry picking mode, rebase mode.
+* `pkg/gui/patch_exploring`: Contains code relating to the state of patch-oriented views like the staging view.
+* `pkg/gui/popup`: Contains code that lets you easily raise popups
+* `pkg/gui/presentation`: Contains presentation code i.e. code concerned with rendering content inside views
+* `pkg/gui/services/custom_commands`: Contains code related to user-defined custom commands.
+* `pkg/gui/status`: Contains code for invoking loaders and toasts
+* `pkg/gui/style`: Contains code for specifying text styles (colour, bold, etc)
+* `pkg/gui/types`: Contains various gui-specific types and interfaces. Lots of code lives here to avoid circular dependencies
+* `vendor/github.com/jesseduffield/gocui`: Gocui is the underlying library used for handling the gui event loop, handling keypresses, and rendering the UI. It defines the View struct which our own context structs build upon.
+
+## Important files
+
+* `pkg/config/user_config.go`: defines the user config and default values
+* `pkg/gui/keybindings.go`: defines keybindings which have not yet been moved into a controller (originally all keybindings were defined here)
+* `pkg/gui/controllers.go`: links up controllers with contexts
+* `pkg/gui/controllers/helpers/helpers.go`: defines all the different helper structs
+* `pkg/commands/git.go`: defines all the different git command structs
+* `pkg/gui/gui.go`: defines the top-level gui state and gui initialisation/run code
+* `pkg/gui/layout.go`: defines what happens on each render
+* `pkg/gui/controllers/helpers/window_arrangement_helper.go`: defines the layout of the UI and the size/position of each window
+* `pkg/gui/context/context.go`: defines the different contexts
+* `pkg/gui/context/setup.go`: defines initialisation code for all contexts
+* `pkg/gui/context.go`: manages the lifecycle of contexts, the context stack, and focus changes.
+* `pkg/gui/types/views.go`: defines views
+* `pkg/gui/views.go`: defines the ordering of views (front to back) and their initialisation code
+* `pkg/gui/gui_common.go`: defines gui-specific methods that all controllers and helpers have access to
+* `pkg/i18n/english.go`: defines the set of i18n strings and their English values
+* `pkg/gui/controllers/helpers/refresh_helper.go`: manages refreshing of models. The refresh helper is typically invoked at the end of an action to re-load affected models from git (e.g. re-load branches after doing a git pull)
+* `pkg/gui/controllers/quit_actions.go`: contains code that runs when you hit 'escape' on a view (assuming the view doesn't define its own escape handler)
+* `vendor/github.com/jesseduffield/gocui/gui.go`: defines the gocui gui struct
+* `vendor/github.com/jesseduffield/gocui/view.go`: defines the gocui view struct
+
+## Concepts
+
+* **View**: Views are defined in the gocui package, and they maintain an internal buffer of content which is rendered each time the screen is drawn.
+* **Context**: A context is tied to a view and contains some additional state and logic specific to that view e.g. the branches context has code relating specifically to branches, and writes the list of branches to the branches view. Views and contexts share some responsibilities for historical reasons.
+* **Controller**: A controller defined keybindings with associated handlers. One controller can be assigned to multiple contexts and one context can have multiple controllers. For example the list controller handles keybindings relating to navigating a list, and is assigned to all list contexts (e.g. the branches context).
+* **Helper**: A helper defines shared code used by controllers, or used by some other parts of the application. Often a controller will have a method that ends up needing to be used by another controller, so in that case we move the method out into a helper so that both controllers can use it. We need to do this because controllers cannot refer to other controllers' methods.
+
+In terms of dependencies, controllers sit at the highest level, so they can refer to helpers, contexts, and views (although it's preferable for view-specific code to live in contexts). Helpers can refer to contexts and views, and contexts can only refer to views. Views can't refer to contexts, controllers, or helpers.
+
+* **Window**: A window is a section of the screen which will render a view. Windows are named after the default view that appears there, so for example there is a 'stash' window that is so named because by default the stash view appears there. But if you press enter on a stash entry, the stash entry's files will be shown in a different view, but in the same window.
+* **Panel**: The term 'panel' is still used in a few places to refer to either a view or a window, and it's a term that is now deprecated in favour of 'view' and 'window'.
+* **Tab**: Each tab in a window (e.g. Files, Worktrees, Submodules) actually has a corresponding view which we bring to the front upon changing tabs.
+* **Model**: Representation of a git object e.g. commits, branches, files.
+* **ViewModel**: Used by a context to maintain state related to the view.
+* **Keybinding**: A keybinding associates a _key_ with an _action_. For example if you press the 'down' arrow, the action performed will be your cursor moving down a list by one.
+* **Action**: An action is the thing that happens when you press a key. Often an action will invoke a git command, but not always: for example, navigation actions don't involve git.
+* **Common structs**: Most structs have a field named `c` which contains a 'common' struct: a struct containing a bag of dependencies that most structs of the same layer require. For example if you want to access a helper from a controller you can do so with `self.c.Helpers.MyHelper`.
+
+## Event loop and threads
+
+The event loop is managed in the `MainLoop` function of `vendor/github.com/jesseduffield/gocui/gui.go`. Any time there is an event like a key press or a window resize, the event will be processed and then the screen will be redrawn. This involves calling the `layout` function defined in `pkg/gui/layout.go`, which lays out the windows and invokes some on-render hooks.
+
+Often, as part of handling a keypress, we'll want to run some code asynchronously so that it doesn't block the UI thread. For this we'll typically run `self.c.OnWorker(myFunc)`. If the worker wants to then do something on the UI thread again it can call `self.c.OnUIThread(myOtherFunc)`.
+
+## Using UserConfig
+
+The UserConfig struct is loaded from lazygit's global config file (and possibly repo-specific config files). It can be re-loaded while lazygit is running, e.g. when the user edits one of the config files. In this case we should make sure that any new or changed config values take effect immediately. The easiest way to achieve this is what we do in most controllers or helpers: these have a pointer to the `common.Common` struct, which contains the UserConfig, and access it from there. Since the UserConfig instance in `common.Common` is updated whenever we reload the config, the code can be sure that it always uses an up-to-date value, and there's nothing else to do.
+
+If that's not possible for some reason, see if you can add code to `Gui.onUserConfigLoaded` to update things from the new config; there are some examples in that function to use as a guide. If that's too hard to do too, add the config to the list in `Gui.checkForChangedConfigsThatDontAutoReload` so that the user is asked to quit and restart lazygit.
+
+## Legacy code structure
+
+Before we had controllers and contexts, all the code lived directly in the gui package under a gui God Struct. This was fairly bloated and so we split things out to have a better separation of concerns. Nonetheless, it's a big effort to migrate all the code so we still have some logic in the gui struct that ought to live somewhere else. Likewise, we have some keybindings defined in `pkg/gui/keybindings.go` that ought to live on a controller (all keybindings used to be defined in that one file).
+
+The new structure has its own problems: we don't have a clear guide on whether code should live in a controller or helper. The current approach is to put code in a controller until it's needed by another controller, and to then extract it out into a helper. We may be better off just putting code in helpers to start with and leaving controllers super-thin, with the responsibility of just pairing keys with corresponding helper functions. But it's not clear to me if that would be better than the current approach.
+
diff --git a/docs-master/dev/Demo_Recordings.md b/docs-master/dev/Demo_Recordings.md
new file mode 100644
index 000000000..1068e688f
--- /dev/null
+++ b/docs-master/dev/Demo_Recordings.md
@@ -0,0 +1,82 @@
+# Demo Recordings
+
+We want our demo recordings to be consistent and easy to update if we make changes to Lazygit's UI. Luckily for us, we have an existing recording system for the sake of our integration tests, so we can piggyback on that.
+
+You'll want to familiarise yourself with how integration tests are written: see [here](../../pkg/integration/README.md).
+
+## Prerequisites
+
+Ideally we'd run this whole thing through docker but we haven't got that working. So you will need:
+```
+# for recording
+npm i -g terminalizer
+# for gif compression
+npm i -g gifsicle
+# for mp4 conversion
+brew install ffmpeg
+
+# font with icons
+wget https://github.com/ryanoasis/nerd-fonts/releases/download/v3.0.2/DejaVuSansMono.tar.xz && \
+ tar -xf DejaVuSansMono.tar.xz -C /usr/local/share/fonts && \
+ rm DejaVuSansMono.tar.xz
+```
+
+## Creating a demo
+
+Demos are found in `pkg/integration/tests/demo/`. They are like regular integration tests but have `IsDemo: true` which has a few effects:
+* The bottom row of the UI is quieter so that we can render captions
+* Fetch/Push/Pull have artificial latency to mimic a network request
+* The loader at the bottom-right does not appear
+
+In demos, we don't need to be as strict in our assertions as we are in tests. But it's still good to have some basic assertions so that if we automate the process of updating demos we'll know if one of them has broken.
+
+You can use the same flow as we use with integration tests when you're writing a demo:
+* Setup the repo
+* Run the demo in sandbox mode to get a feel of what needs to happen
+* Come back and write the code to make it happen
+
+### Adding captions
+
+It's good to add captions explaining what task if being performed. Use the existing demos as a guide.
+
+### Setting up the assets worktree
+
+We store assets (which includes demo recordings) in the `assets` branch, which is a branch that shares no history with the main branch and exists purely for storing assets. Storing them separately means we don't clog up the code branches with large binaries.
+
+The scripts and demo definitions live in the code branches but the output lives in the assets branch so to be able to create a video from a demo you'll need to create a linked worktree for the assets branch which you can do with:
+
+```sh
+git worktree add .worktrees/assets assets
+```
+
+Outputs will be stored in `.worktrees/assets/demos/`. We'll store three separate things:
+* the yaml of the recording
+* the original gif
+* either the compressed gif or the mp4 depending on the output you chose (see below)
+
+### Recording the demo
+
+Once you're happy with your demo you can record it using:
+```sh
+scripts/record_demo.sh [gif|mp4]
+# e.g.
+scripts/record_demo.sh gif pkg/integration/tests/demo/interactive_rebase.go
+```
+
+~~The gif format is for use in the first video of the readme (it has a larger size but has auto-play and looping)~~
+~~The mp4 format is for everything else (no looping, requires clicking, but smaller size).~~
+
+Turns out that you can't store mp4s in a repo and link them from a README so we're gonna just use gifs across the board for now.
+
+### Including demos in README/docs
+
+If you've followed the above steps you'll end up with your output in your assets worktree.
+
+Within that worktree, stage all three output files and raise a PR against the assets branch.
+
+Then back in the code branch, in the doc, you can embed the recording like so:
+```md
+
+```
+
+This means we can update assets without needing to update the docs that embed them.
diff --git a/docs-master/dev/Find_Base_Commit_For_Fixup_Design.md b/docs-master/dev/Find_Base_Commit_For_Fixup_Design.md
new file mode 100644
index 000000000..cf28bdae2
--- /dev/null
+++ b/docs-master/dev/Find_Base_Commit_For_Fixup_Design.md
@@ -0,0 +1,229 @@
+# About the mechanics of lazygit's "Find base commit for fixup" command
+
+## Background
+
+Lazygit has a command called "Find base commit for fixup" that helps with
+creating fixup commits. (It is bound to "ctrl-f" by default, and I'll call it
+simply "the ctrl-f command" throughout the rest of this text for brevity.)
+
+It's a heuristic that needs to make a few assumptions; it tends to work well in
+practice if users are aware of its limitations. The user-facing side of the
+topic is explained [here](../Fixup_Commits.md). In this document we describe how
+it works internally, and the design decisions behind it.
+
+It is also interesting to compare it to the standalone tool
+[git-absorb](https://github.com/tummychow/git-absorb) which does a very similar
+thing, but made different decisions in some cases. We'll explore these
+differences in this document.
+
+## Design goals
+
+I'll start with git-absorb's design goals (my interpretation, since I can't
+speak for git-absorb's maintainer of course): its main goal seems to be minimum
+user interaction required. The idea is that you have a PR in review, the
+reviewer requested a bunch of changes, you make all these changes, so you have a
+working copy with lots of modified files, and then you fire up git-absorb and it
+creates all the necessary fixup commits automatically with no further user
+intervention.
+
+While this sounds attractive, it conflicts with ctrl-f's main design goal, which
+is to support creating high-quality fixups. My philosophy is that fixup commits
+should have the same high quality standards as normal commits; in particular:
+
+- they should be atomic. This means that multiple diff hunks that belong
+ together to form one logical change should be in the same fixup commit. (Not
+ always possible if the logical change needs to be fixed up into several
+ different base commits.)
+- they should be minimal. Every fixup commit should ideally contain only one
+ logical change, not several unrelated ones.
+
+Why is this important? Because fixup commits are mainly a tool for reviewing (if
+they weren't, you might as well squash the changes into their base commits right
+away). And reviewing fixup commits is easier if they are well-structured, just
+like normal commits.
+
+The only way to achieve this with git-absorb is to set the `oneFixupPerCommit`
+config option (for the first goal), and then manually stage the changes that
+belong together (for the second). This is close to what you have to do with
+ctrl-f, with one exception that we'll get to below.
+
+But ctrl-f enforces this by refusing to do the job if the staged hunks belong to
+more than one base commit. Git-absorb will happily create multiple fixup commits
+in this case; ctrl-f doesn't, to enforce that you pay attention to how you group
+the changes. There's another reason for this behavior: ctrl-f doesn't create
+fixup commits itself (unlike git-absorb), instead it just selects the found base
+commit so that the user can decide whether to amend the changes right in, or
+create a fixup commit from there (both are single-key commands in lazygit). And
+lazygit doesn't support non-contiguous multiselections of commits, but even if
+it did, it wouldn't help much in this case.
+
+## The mechanics
+
+### General approach
+
+Git-absorb uses a relatively simple approach, and the benefit is of course that
+it is easy to understand: it looks at every diff hunk separately, and for every
+hunk it looks at all commits (starting from the newest one backwards) to find
+the earliest commit that the change can be amended to without conflicts.
+
+It is important to realize that "diff hunk" doesn't necessarily mean what you
+see in the diff view. Git-absorb and ctrl-f both use a context of 0 when diffing
+your code, so they often see more and smaller hunks than users do. For example,
+moving a line of code down by one line is a single hunk for users, but it's two
+separate hunks for git-absorb and ctrl-f; one for deleting the line at the old
+place, and another one for adding the line at the new place, even if it's only
+one line further down.
+
+From this, it follows that there's one big problem with git-absorb's approach:
+when moving code, it doesn't realize that the two related hunks of deleting the
+code from the old place and inserting it at the new place belong together, and
+often it will manage to create a fixup commit for the first hunk, but leave the
+other hunk in your working copy as "don't know what to do with this". As an
+example, suppose your PR is adding a line of code to an existing function, maybe
+one that declares a new variable, and a reviewer suggests to move this line down
+a bit, closer to where some other related variables are declared. Moving the
+line down results in two diff hunks (from the perspective of git-absorb and
+ctrl-f, as they both use a context of 0 when diffing), and when looking at the
+second diff hunk in isolation there's no way to find a base commit in your PR
+for it, because the surrounding code is already on main.
+
+To solve this, the ctrl-f command makes a distinction between hunks that have
+deleted lines and hunks that have only added lines. If the whole diff contains
+any hunks that have deleted lines, it uses only those hunks to determine the
+base commit, and then assumes that all the hunks that have only added lines
+belong into the same commit. This nicely solves the above example of moving
+code, but also other examples such as the following:
+
+
+Click to show example
+
+Suppose you have a PR in which you added the following function:
+
+```go
+func findCommit(hash string) (*models.Commit, int, bool) {
+ for i, commit := range self.c.Model().Commits {
+ if commit.Hash == hash {
+ return commit, i, true
+ }
+ }
+
+ return nil, -1, false
+}
+```
+
+A reviewer suggests to replace the manual `for` loop with a call to
+`lo.FindIndexOf` since that's less code and more idiomatic. So your modification
+is this:
+
+```diff
+--- a/my_file.go
++++ b/my_file.go
+@@ -12,2 +12,3 @@ import (
+ "github.com/jesseduffield/lazygit/pkg/utils"
++ "github.com/samber/lo"
+ "golang.org/x/sync/errgroup"
+@@ -308,9 +309,5 @@ func (self *FixupHelper) blameAddedLines(addedLineHunks []*hunk) ([]string, error
+ func findCommit(hash string) (*models.Commit, int, bool) {
+- for i, commit := range self.c.Model().Commits {
+- if commit.Hash == hash {
+- return commit, i, true
+- }
+- }
+-
+- return nil, -1, false
++ return lo.FindIndexOf(self.c.Model().Commits, func(commit *models.Commit) bool {
++ return commit.Hash == hash
++ })
+ }
+```
+
+If we were to look at these two hunks separately, we'd easily find the base
+commit for the second one, but we wouldn't find the one for the first hunk
+because the imports around the added import have been on main for a long time.
+In fact, git-absorb leaves this hunk in the working copy because it doesn't know
+what to do with it.
+
+
+
+Only if there are no hunks with deleted lines does ctrl-f look at the hunks with
+only added lines and determines the base commit for them. This solves cases like
+adding a comment above a function that you added in your PR.
+
+The downside of this more complicated approach is that it relies on the user
+staging related hunks correctly. However, in my experience this is easy to do
+and not very error-prone, as long as users are aware of this behavior. Lazygit
+tries to help making them aware of it by showing a warning whenever there are
+hunks with only added lines in addition to hunks with deleted lines.
+
+### Finding the base commit for a given hunk
+
+As explained above, git-absorb finds the base commit by walking the commits
+backwards until it finds one that conflicts with the hunk, and then the found
+base commit is the one just before that one. This works reliably, but it is
+slow.
+
+Ctrl-f uses a different approach that is usually much faster, but should always
+yield the same result. Again, it makes a distinction between hunks with deleted
+lines and hunks with only added lines. For hunks with deleted lines it performs
+a line range blame for all the deleted lines (e.g. `git blame -L42,+3 --
+filename`), and if the result is the same for all deleted lines, then that's the
+base commit; otherwise it returns an error.
+
+For hunks with only added lines, it gets a little more complicated. We blame the
+single lines just before and just after the hunk (I'll ignore the edge cases of
+either of those not existing because the hunk is at the beginning or end of the
+file; read the code to see how we handle these cases). If the blame result is
+the same for both, then that's the base commit. This is the case of adding a
+line in the middle of a block of code that was added in the PR. Otherwise, the
+base commit is the more recent of the two (and in this case it doesn't matter if
+the other one is an earlier commit in the current branch, or a possibly very old
+commit that's already on main). This covers the common case of adding a comment
+to a function that was added in the PR, but also adding another line at the end
+of a block of code that was added in the base commit.
+
+It's interesting to discuss what "more recent" means here. You could say if
+commit A is an ancestor of commit B (or in other words, A is reachable from B)
+then B is the more recent one. And if none of the two commits is reachable from
+the other, you have an error case because it's unclear which of the two should
+be considered the base commit. The scenario in which this happens is a commit
+history like this:
+
+```
+ C---D
+ / \
+A---B---E---F---G
+```
+
+where, for instance, D and E are the two blame results.
+
+Unfortunately, determining the ancestry relationship between two commits using
+git commands is a bit expensive and not totally straightforward. Fortunately,
+it's not necessary in lazygit because lazygit has the most recent 300 commits
+cached in memory, and can simply search its linear list of commits to see which
+one is closer to the beginning of the list. If only one of the two commits is
+found within those 300 commits, then that's the more recent one; if neither is
+found, we assume that both commits are on main and error out. In the merge
+scenario pictured above, we arbitrarily return one of the two commits (this will
+depend on the log order), but that's probably fine as this scenario should be
+extremely rare in practice; in most cases, feature branches are simply linear.
+
+### Knowing where to stop searching
+
+Git-absorb needs to know when to stop walking backwards searching for commits,
+since it doesn't make sense to create fixups for commits that are already on
+main. However, it doesn't know where the current branch ends and main starts, so
+it needs to rely on user input for this. By default it searches the most recent
+10 commits, but this can be overridden with a config setting. In longer branches
+this is often not enough for finding the base commit; but setting it to a higher
+value causes the command to take longer to complete when the base commit can't
+be found.
+
+Lazygit doesn't have this problem. For a given blame result it needs to
+determine whether that commit is already on main, and if it can find the commit
+in its cached list of the first 300 commits it can get that information from
+there, because lazygit knows what the user's configured main branches are
+(`master` and `main` by default, but it could also include branches like `devel`
+or `1.0-hotfixes`), and so it can tell for each commit whether it's contained in
+one of those main branches. And if it can't find it among the first 300 commits,
+it assumes the commit already on main, on the assumption that no feature branch
+has more than 300 commits.
diff --git a/docs-master/dev/Integration_Tests.md b/docs-master/dev/Integration_Tests.md
new file mode 100644
index 000000000..df10c3f8f
--- /dev/null
+++ b/docs-master/dev/Integration_Tests.md
@@ -0,0 +1 @@
+see new docs [here](../../pkg/integration/README.md)
diff --git a/docs-master/dev/Profiling.md b/docs-master/dev/Profiling.md
new file mode 100644
index 000000000..bfdffe4f9
--- /dev/null
+++ b/docs-master/dev/Profiling.md
@@ -0,0 +1,69 @@
+# Profiling Lazygit
+
+If you want to investigate what's contributing to CPU or memory usage, start
+lazygit with the `-profile` command line flag. This tells it to start an
+integrated web server that listens for profiling requests.
+
+## Save profile data
+
+### CPU
+
+While lazygit is running with the `-profile` flag, perform a CPU profile and
+save it to a file by running this command in another terminal window:
+
+```sh
+curl -o cpu.out http://127.0.0.1:6060/debug/pprof/profile
+```
+
+By default, it profiles for 30 seconds. To change the duration, use
+
+```sh
+curl -o cpu.out 'http://127.0.0.1:6060/debug/pprof/profile?seconds=60'
+```
+
+### Memory
+
+To save a heap profile (containing information about all memory allocated so
+far since startup), use
+
+```sh
+curl -o mem.out http://127.0.0.1:6060/debug/pprof/heap
+```
+
+Sometimes it can be useful to get a delta log, i.e. to see how memory usage
+developed from one point in time to another. For that, use
+
+```sh
+curl -o mem.out 'http://127.0.0.1:6060/debug/pprof/heap?seconds=20'
+```
+
+This will log the memory usage difference between now and 20 seconds later, so
+it gives you 20 seconds to perform the action in lazygit that you are interested
+in measuring.
+
+## View profile data
+
+To display the profile data, you can either use speedscope.app, or the pprof
+tool that comes with go. I prefer the former because it has a nicer UI and is a
+little more powerful; however, I have seen cases where it wasn't able to load a
+profile for some reason, in which case it's good to have the pprof tool as a
+fallback.
+
+### Speedscope.app
+
+Go to https://www.speedscope.app/ in your browser, and drag the saved profile
+onto the browser window. Refer to [the
+documentation](https://github.com/jlfwong/speedscope?tab=readme-ov-file#usage)
+for how to navigate the data.
+
+### Pprof tool
+
+To view a profile that you saved as `cpu.out`, use
+
+```sh
+go tool pprof -http=:8080 cpu.out
+```
+
+By default this shows the graph view, which I don't find very useful myself.
+Choose "Flame Graph" from the View menu to show a much more useful
+representation of the data.
diff --git a/docs-master/dev/README.md b/docs-master/dev/README.md
new file mode 100644
index 000000000..fcfcf2741
--- /dev/null
+++ b/docs-master/dev/README.md
@@ -0,0 +1,8 @@
+# Dev Documentation Overview
+
+* [Codebase Guide](./Codebase_Guide.md)
+* [Busy/Idle Tracking](./Busy.md)
+* [Integration Tests](../../pkg/integration/README.md)
+* [Demo Recordings](./Demo_Recordings.md)
+* [Find base commit for fixup design](Find_Base_Commit_For_Fixup_Design.md)
+* [Profiling](Profiling.md)
diff --git a/docs-master/keybindings/Custom_Keybindings.md b/docs-master/keybindings/Custom_Keybindings.md
new file mode 100644
index 000000000..a2537f069
--- /dev/null
+++ b/docs-master/keybindings/Custom_Keybindings.md
@@ -0,0 +1,63 @@
+## Possible keybindings
+| Put in | You will get |
+|---------------|----------------|
+| `` | F1 |
+| `` | F2 |
+| `` | F3 |
+| `` | F4 |
+| `` | F5 |
+| `` | F6 |
+| `` | F7 |
+| `` | F8 |
+| `` | F9 |
+| `` | F10 |
+| `` | F11 |
+| `` | F12 |
+| `` | Insert |
+| `` | Delete |
+| `` | Home |
+| `` | End |
+| `` | Pgup |
+| `` | Pgdn |
+| `` | ArrowUp |
+| `` | ShiftArrowUp |
+| `` | ArrowDown |
+| `` | ShiftArrowDown |
+| `` | ArrowLeft |
+| `` | ArrowRight |
+| `` | Tab |
+| `` | Backtab |
+| `` | Enter |
+| `` | AltEnter |
+| `` | Esc |
+| `` | Backspace |
+| `` | CtrlSpace |
+| `` | CtrlSlash |
+| `` | Space |
+| `` | CtrlA |
+| `` | CtrlB |
+| `` | CtrlC |
+| `` | CtrlD |
+| `` | CtrlE |
+| `` | CtrlF |
+| `` | CtrlG |
+| `` | CtrlJ |
+| `` | CtrlK |
+| `` | CtrlL |
+| `` | CtrlN |
+| `` | CtrlO |
+| `` | CtrlP |
+| `` | CtrlQ |
+| `` | CtrlR |
+| `` | CtrlS |
+| `` | CtrlT |
+| `` | CtrlU |
+| `` | CtrlV |
+| `` | CtrlW |
+| `` | CtrlX |
+| `` | CtrlY |
+| `` | CtrlZ |
+| `` | Ctrl4 |
+| `` | Ctrl5 |
+| `` | Ctrl6 |
+| `` | Ctrl8 |
diff --git a/docs-master/keybindings/Keybindings_en.md b/docs-master/keybindings/Keybindings_en.md
new file mode 100644
index 000000000..bbbd3e2e8
--- /dev/null
+++ b/docs-master/keybindings/Keybindings_en.md
@@ -0,0 +1,414 @@
+_This file is auto-generated. To update, make the changes in the pkg/i18n directory and then run `go generate ./...` from the project root._
+
+# Lazygit Keybindings
+
+_Legend: `` means ctrl+b, `` means alt+b, `B` means shift+b_
+
+## Global keybindings
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Switch to a recent repo | |
+| `` (fn+up/shift+k) `` | Scroll up main window | |
+| `` (fn+down/shift+j) `` | Scroll down main window | |
+| `` @ `` | View command log options | View options for the command log e.g. show/hide the command log and focus the command log. |
+| `` P `` | Push | Push the current branch to its upstream branch. If no upstream is configured, you will be prompted to configure an upstream branch. |
+| `` p `` | Pull | Pull changes from the remote for the current branch. If no upstream is configured, you will be prompted to configure an upstream branch. |
+| `` ) `` | Increase rename similarity threshold | Increase the similarity threshold for a deletion and addition pair to be treated as a rename.
The default can be changed in the config file with the key 'git.renameSimilarityThreshold'. |
+| `` ( `` | Decrease rename similarity threshold | Decrease the similarity threshold for a deletion and addition pair to be treated as a rename.
The default can be changed in the config file with the key 'git.renameSimilarityThreshold'. |
+| `` } `` | Increase diff context size | Increase the amount of the context shown around changes in the diff view.
The default can be changed in the config file with the key 'git.diffContextSize'. |
+| `` { `` | Decrease diff context size | Decrease the amount of the context shown around changes in the diff view.
The default can be changed in the config file with the key 'git.diffContextSize'. |
+| `` : `` | Execute shell command | Bring up a prompt where you can enter a shell command to execute. |
+| `` `` | View custom patch options | |
+| `` m `` | View merge/rebase options | View options to abort/continue/skip the current merge/rebase. |
+| `` R `` | Refresh | Refresh the git state (i.e. run `git status`, `git branch`, etc in background to update the contents of panels). This does not run `git fetch`. |
+| `` + `` | Next screen mode (normal/half/fullscreen) | |
+| `` _ `` | Prev screen mode | |
+| `` \| `` | Cycle pagers | Choose the next pager in the list of configured pagers |
+| `` `` | Cancel | |
+| `` ? `` | Open keybindings menu | |
+| `` `` | View filter options | View options for filtering the commit log, so that only commits matching the filter are shown. |
+| `` W `` | View diffing options | View options relating to diffing two refs e.g. diffing against selected ref, entering ref to diff against, and reversing the diff direction. |
+| `` `` | View diffing options | View options relating to diffing two refs e.g. diffing against selected ref, entering ref to diff against, and reversing the diff direction. |
+| `` q `` | Quit | |
+| `` `` | Suspend the application | |
+| `` `` | Toggle whitespace | Toggle whether or not whitespace changes are shown in the diff view.
The default can be changed in the config file with the key 'git.ignoreWhitespaceInDiffView'. |
+| `` z `` | Undo | The reflog will be used to determine what git command to run to undo the last git command. This does not include changes to the working tree; only commits are taken into consideration. |
+| `` Z `` | Redo | The reflog will be used to determine what git command to run to redo the last git command. This does not include changes to the working tree; only commits are taken into consideration. |
+
+## List panel navigation
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` , `` | Previous page | |
+| `` . `` | Next page | |
+| `` < () `` | Scroll to top | |
+| `` > () `` | Scroll to bottom | |
+| `` v `` | Toggle range select | |
+| `` `` | Range select down | |
+| `` `` | Range select up | |
+| `` / `` | Search the current view by text | |
+| `` H `` | Scroll left | |
+| `` L `` | Scroll right | |
+| `` ] `` | Next tab | |
+| `` [ `` | Previous tab | |
+
+## Commit files
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Copy path to clipboard | |
+| `` y `` | Copy to clipboard | |
+| `` c `` | Checkout | Checkout file. This replaces the file in your working tree with the version from the selected commit. |
+| `` d `` | Remove | Discard this commit's changes to this file. This runs an interactive rebase in the background, so you may get a merge conflict if a later commit also changes this file. |
+| `` o `` | Open file | Open file in default application. |
+| `` e `` | Edit | Open file in external editor. |
+| `` `` | Open external diff tool (git difftool) | |
+| `` `` | Toggle file included in patch | Toggle whether the file is included in the custom patch. See https://github.com/jesseduffield/lazygit#rebase-magic-custom-patches. |
+| `` a `` | Toggle all files | Add/remove all commit's files to custom patch. See https://github.com/jesseduffield/lazygit#rebase-magic-custom-patches. |
+| `` `` | Enter file / Toggle directory collapsed | If a file is selected, enter the file so that you can add/remove individual lines to the custom patch. If a directory is selected, toggle the directory. |
+| `` ` `` | Toggle file tree view | Toggle file view between flat and tree layout. Flat layout shows all file paths in a single list, tree layout groups files by directory.
The default can be changed in the config file with the key 'gui.showFileTree'. |
+| `` - `` | Collapse all files | Collapse all directories in the files tree |
+| `` = `` | Expand all files | Expand all directories in the file tree |
+| `` 0 `` | Focus main view | |
+| `` / `` | Search the current view by text | |
+
+## Commit summary
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Confirm | |
+| `` `` | Close | |
+
+## Commits
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Copy commit hash to clipboard | |
+| `` `` | Reset copied (cherry-picked) commits selection | |
+| `` b `` | View bisect options | |
+| `` s `` | Squash | Squash the selected commit into the commit below it. The selected commit's message will be appended to the commit below it. |
+| `` f `` | Fixup | Meld the selected commit into the commit below it. Similar to squash, but the selected commit's message will be discarded. |
+| `` r `` | Reword | Reword the selected commit's message. |
+| `` R `` | Reword with editor | |
+| `` d `` | Drop | Drop the selected commit. This will remove the commit from the branch via a rebase. If the commit makes changes that later commits depend on, you may need to resolve merge conflicts. |
+| `` e `` | Edit (start interactive rebase) | Edit the selected commit. Use this to start an interactive rebase from the selected commit. When already mid-rebase, this will mark the selected commit for editing, which means that upon continuing the rebase, the rebase will pause at the selected commit to allow you to make changes. |
+| `` i `` | Start interactive rebase | Start an interactive rebase for the commits on your branch. This will include all commits from the HEAD commit down to the first merge commit or main branch commit.
If you would instead like to start an interactive rebase from the selected commit, press `e`. |
+| `` p `` | Pick | Mark the selected commit to be picked (when mid-rebase). This means that the commit will be retained upon continuing the rebase. |
+| `` F `` | Create fixup commit | Create 'fixup!' commit for the selected commit. Later on, you can press `S` on this same commit to apply all above fixup commits. |
+| `` S `` | Apply fixup commits | Squash all 'fixup!' commits, either above the selected commit, or all in current branch (autosquash). |
+| `` `` | Move commit down one | |
+| `` `` | Move commit up one | |
+| `` V `` | Paste (cherry-pick) | |
+| `` B `` | Mark as base commit for rebase | Select a base commit for the next rebase. When you rebase onto a branch, only commits above the base commit will be brought across. This uses the `git rebase --onto` command. |
+| `` A `` | Amend | Amend commit with staged changes. If the selected commit is the HEAD commit, this will perform `git commit --amend`. Otherwise the commit will be amended via a rebase. |
+| `` a `` | Amend commit attribute | Set/Reset commit author or set co-author. |
+| `` t `` | Revert | Create a revert commit for the selected commit, which applies the selected commit's changes in reverse. |
+| `` T `` | Tag commit | Create a new tag pointing at the selected commit. You'll be prompted to enter a tag name and optional description. |
+| `` `` | View log options | View options for commit log e.g. changing sort order, hiding the git graph, showing the whole git graph. |
+| `` `` | Checkout | Checkout the selected commit as a detached HEAD. |
+| `` y `` | Copy commit attribute to clipboard | Copy commit attribute to clipboard (e.g. hash, URL, diff, message, author). |
+| `` o `` | Open commit in browser | |
+| `` n `` | Create new branch off of commit | |
+| `` N `` | Move commits to new branch | Create a new branch and move the unpushed commits of the current branch to it. Useful if you meant to start new work and forgot to create a new branch first.
Note that this disregards the selection, the new branch is always created either from the main branch or stacked on top of the current branch (you get to choose which). |
+| `` g `` | Reset | View reset options (soft/mixed/hard) for resetting onto selected item. |
+| `` C `` | Copy (cherry-pick) | Mark commit as copied. Then, within the local commits view, you can press `V` to paste (cherry-pick) the copied commit(s) into your checked out branch. At any time you can press `` to cancel the selection. |
+| `` `` | Open external diff tool (git difftool) | |
+| `` * `` | Select commits of current branch | |
+| `` 0 `` | Focus main view | |
+| `` `` | View files | |
+| `` w `` | View worktree options | |
+| `` / `` | Search the current view by text | |
+
+## Confirmation panel
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Confirm | |
+| `` `` | Close/Cancel | |
+| `` `` | Copy to clipboard | |
+
+## Files
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Copy path to clipboard | |
+| `` `` | Stage | Toggle staged for selected file. |
+| `` `` | Filter files by status | |
+| `` y `` | Copy to clipboard | |
+| `` c `` | Commit | Commit staged changes. |
+| `` w `` | Commit changes without pre-commit hook | |
+| `` A `` | Amend last commit | |
+| `` C `` | Commit changes using git editor | |
+| `` `` | Find base commit for fixup | Find the commit that your current changes are building upon, for the sake of amending/fixing up the commit. This spares you from having to look through your branch's commits one-by-one to see which commit should be amended/fixed up. See docs: |
+| `` e `` | Edit | Open file in external editor. |
+| `` o `` | Open file | Open file in default application. |
+| `` i `` | Ignore or exclude file | |
+| `` r `` | Refresh files | |
+| `` s `` | Stash | Stash all changes. For other variations of stashing, use the view stash options keybinding. |
+| `` S `` | View stash options | View stash options (e.g. stash all, stash staged, stash unstaged). |
+| `` a `` | Stage all | Toggle staged/unstaged for all files in working tree. |
+| `` `` | Stage lines / Collapse directory | If the selected item is a file, focus the staging view so you can stage individual hunks/lines. If the selected item is a directory, collapse/expand it. |
+| `` d `` | Discard | View options for discarding changes to the selected file. |
+| `` g `` | View upstream reset options | |
+| `` D `` | Reset | View reset options for working tree (e.g. nuking the working tree). |
+| `` ` `` | Toggle file tree view | Toggle file view between flat and tree layout. Flat layout shows all file paths in a single list, tree layout groups files by directory.
The default can be changed in the config file with the key 'gui.showFileTree'. |
+| `` `` | Open external diff tool (git difftool) | |
+| `` M `` | View merge conflict options | View options for resolving merge conflicts. |
+| `` f `` | Fetch | Fetch changes from remote. |
+| `` - `` | Collapse all files | Collapse all directories in the files tree |
+| `` = `` | Expand all files | Expand all directories in the file tree |
+| `` 0 `` | Focus main view | |
+| `` / `` | Search the current view by text | |
+
+## Input prompt
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Confirm | |
+| `` `` | Close/Cancel | |
+
+## Local branches
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Copy branch name to clipboard | |
+| `` i `` | Show git-flow options | |
+| `` `` | Checkout | Checkout selected item. |
+| `` n `` | New branch | |
+| `` N `` | Move commits to new branch | Create a new branch and move the unpushed commits of the current branch to it. Useful if you meant to start new work and forgot to create a new branch first.
Note that this disregards the selection, the new branch is always created either from the main branch or stacked on top of the current branch (you get to choose which). |
+| `` o `` | Create pull request | |
+| `` O `` | View create pull request options | |
+| `` `` | Copy pull request URL to clipboard | |
+| `` c `` | Checkout by name | Checkout by name. In the input box you can enter '-' to switch to the previous branch. |
+| `` - `` | Checkout previous branch | |
+| `` F `` | Force checkout | Force checkout selected branch. This will discard all local changes in your working directory before checking out the selected branch. |
+| `` d `` | Delete | View delete options for local/remote branch. |
+| `` r `` | Rebase | Rebase the checked-out branch onto the selected branch. |
+| `` M `` | Merge | View options for merging the selected item into the current branch (regular merge, squash merge) |
+| `` f `` | Fast-forward | Fast-forward selected branch from its upstream. |
+| `` T `` | New tag | |
+| `` s `` | Sort order | |
+| `` g `` | Reset | |
+| `` R `` | Rename branch | |
+| `` u `` | View upstream options | View options relating to the branch's upstream e.g. setting/unsetting the upstream and resetting to the upstream. |
+| `` `` | Open external diff tool (git difftool) | |
+| `` 0 `` | Focus main view | |
+| `` `` | View commits | |
+| `` w `` | View worktree options | |
+| `` / `` | Filter the current view by text | |
+
+## Main panel (merging)
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Pick hunk | |
+| `` b `` | Pick all hunks | |
+| `` `` | Previous hunk | |
+| `` `` | Next hunk | |
+| `` `` | Previous conflict | |
+| `` `` | Next conflict | |
+| `` z `` | Undo | Undo last merge conflict resolution. |
+| `` e `` | Edit file | Open file in external editor. |
+| `` o `` | Open file | Open file in default application. |
+| `` M `` | View merge conflict options | View options for resolving merge conflicts. |
+| `` `` | Return to files panel | |
+
+## Main panel (normal)
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` mouse wheel down (fn+up) `` | Scroll down | |
+| `` mouse wheel up (fn+down) `` | Scroll up | |
+| `` `` | Switch view | Switch to other view (staged/unstaged changes). |
+| `` `` | Exit back to side panel | |
+| `` / `` | Search the current view by text | |
+
+## Main panel (patch building)
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Go to previous hunk | |
+| `` `` | Go to next hunk | |
+| `` v `` | Toggle range select | |
+| `` a `` | Toggle hunk selection | Toggle line-by-line vs. hunk selection mode. |
+| `` `` | Copy selected text to clipboard | |
+| `` o `` | Open file | Open file in default application. |
+| `` e `` | Edit file | Open file in external editor. |
+| `` `` | Toggle lines in patch | |
+| `` `` | Exit custom patch builder | |
+| `` / `` | Search the current view by text | |
+
+## Main panel (staging)
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Go to previous hunk | |
+| `` `` | Go to next hunk | |
+| `` v `` | Toggle range select | |
+| `` a `` | Toggle hunk selection | Toggle line-by-line vs. hunk selection mode. |
+| `` `` | Copy selected text to clipboard | |
+| `` `` | Stage | Toggle selection staged / unstaged. |
+| `` d `` | Discard | When unstaged change is selected, discard the change using `git reset`. When staged change is selected, unstage the change. |
+| `` o `` | Open file | Open file in default application. |
+| `` e `` | Edit file | Open file in external editor. |
+| `` `` | Return to files panel | |
+| `` `` | Switch view | Switch to other view (staged/unstaged changes). |
+| `` E `` | Edit hunk | Edit selected hunk in external editor. |
+| `` c `` | Commit | Commit staged changes. |
+| `` w `` | Commit changes without pre-commit hook | |
+| `` C `` | Commit changes using git editor | |
+| `` `` | Find base commit for fixup | Find the commit that your current changes are building upon, for the sake of amending/fixing up the commit. This spares you from having to look through your branch's commits one-by-one to see which commit should be amended/fixed up. See docs: |
+| `` / `` | Search the current view by text | |
+
+## Menu
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Execute | |
+| `` `` | Close/Cancel | |
+| `` / `` | Filter the current view by text | |
+
+## Reflog
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Copy commit hash to clipboard | |
+| `` `` | Checkout | Checkout the selected commit as a detached HEAD. |
+| `` y `` | Copy commit attribute to clipboard | Copy commit attribute to clipboard (e.g. hash, URL, diff, message, author). |
+| `` o `` | Open commit in browser | |
+| `` n `` | Create new branch off of commit | |
+| `` N `` | Move commits to new branch | Create a new branch and move the unpushed commits of the current branch to it. Useful if you meant to start new work and forgot to create a new branch first.
Note that this disregards the selection, the new branch is always created either from the main branch or stacked on top of the current branch (you get to choose which). |
+| `` g `` | Reset | View reset options (soft/mixed/hard) for resetting onto selected item. |
+| `` C `` | Copy (cherry-pick) | Mark commit as copied. Then, within the local commits view, you can press `V` to paste (cherry-pick) the copied commit(s) into your checked out branch. At any time you can press `` to cancel the selection. |
+| `` `` | Reset copied (cherry-picked) commits selection | |
+| `` `` | Open external diff tool (git difftool) | |
+| `` * `` | Select commits of current branch | |
+| `` 0 `` | Focus main view | |
+| `` `` | View commits | |
+| `` w `` | View worktree options | |
+| `` / `` | Filter the current view by text | |
+
+## Remote branches
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Copy branch name to clipboard | |
+| `` `` | Checkout | Checkout a new local branch based on the selected remote branch, or the remote branch as a detached head. |
+| `` n `` | New branch | |
+| `` M `` | Merge | View options for merging the selected item into the current branch (regular merge, squash merge) |
+| `` r `` | Rebase | Rebase the checked-out branch onto the selected branch. |
+| `` d `` | Delete | Delete the remote branch from the remote. |
+| `` u `` | Set as upstream | Set the selected remote branch as the upstream of the checked-out branch. |
+| `` s `` | Sort order | |
+| `` g `` | Reset | View reset options (soft/mixed/hard) for resetting onto selected item. |
+| `` `` | Open external diff tool (git difftool) | |
+| `` 0 `` | Focus main view | |
+| `` `` | View commits | |
+| `` w `` | View worktree options | |
+| `` / `` | Filter the current view by text | |
+
+## Remotes
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | View branches | |
+| `` n `` | New remote | |
+| `` d `` | Remove | Remove the selected remote. Any local branches tracking a remote branch from the remote will be unaffected. |
+| `` e `` | Edit | Edit the selected remote's name or URL. |
+| `` f `` | Fetch | Fetch updates from the remote repository. This retrieves new commits and branches without merging them into your local branches. |
+| `` F `` | Add fork remote | Quickly add a fork remote by replacing the owner in the origin URL and optionally check out a branch from new remote. |
+| `` / `` | Filter the current view by text | |
+
+## Secondary
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Switch view | Switch to other view (staged/unstaged changes). |
+| `` `` | Exit back to side panel | |
+| `` / `` | Search the current view by text | |
+
+## Stash
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Apply | Apply the stash entry to your working directory. |
+| `` g `` | Pop | Apply the stash entry to your working directory and remove the stash entry. |
+| `` d `` | Drop | Remove the stash entry from the stash list. |
+| `` n `` | New branch | Create a new branch from the selected stash entry. This works by git checking out the commit that the stash entry was created from, creating a new branch from that commit, then applying the stash entry to the new branch as an additional commit. |
+| `` r `` | Rename stash | |
+| `` 0 `` | Focus main view | |
+| `` `` | View files | |
+| `` w `` | View worktree options | |
+| `` / `` | Filter the current view by text | |
+
+## Status
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` o `` | Open config file | Open file in default application. |
+| `` e `` | Edit config file | Open file in external editor. |
+| `` u `` | Check for update | |
+| `` `` | Switch to a recent repo | |
+| `` a `` | Show/cycle all branch logs | |
+| `` 0 `` | Focus main view | |
+
+## Sub-commits
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Copy commit hash to clipboard | |
+| `` `` | Checkout | Checkout the selected commit as a detached HEAD. |
+| `` y `` | Copy commit attribute to clipboard | Copy commit attribute to clipboard (e.g. hash, URL, diff, message, author). |
+| `` o `` | Open commit in browser | |
+| `` n `` | Create new branch off of commit | |
+| `` N `` | Move commits to new branch | Create a new branch and move the unpushed commits of the current branch to it. Useful if you meant to start new work and forgot to create a new branch first.
Note that this disregards the selection, the new branch is always created either from the main branch or stacked on top of the current branch (you get to choose which). |
+| `` g `` | Reset | View reset options (soft/mixed/hard) for resetting onto selected item. |
+| `` C `` | Copy (cherry-pick) | Mark commit as copied. Then, within the local commits view, you can press `V` to paste (cherry-pick) the copied commit(s) into your checked out branch. At any time you can press `` to cancel the selection. |
+| `` `` | Reset copied (cherry-picked) commits selection | |
+| `` `` | Open external diff tool (git difftool) | |
+| `` * `` | Select commits of current branch | |
+| `` 0 `` | Focus main view | |
+| `` `` | View files | |
+| `` w `` | View worktree options | |
+| `` / `` | Search the current view by text | |
+
+## Submodules
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Copy submodule name to clipboard | |
+| `` `` | Enter | Enter submodule. After entering the submodule, you can press `` to escape back to the parent repo. |
+| `` d `` | Remove | Remove the selected submodule and its corresponding directory. |
+| `` u `` | Update | Update selected submodule. |
+| `` n `` | New submodule | |
+| `` e `` | Update submodule URL | |
+| `` i `` | Initialize | Initialize the selected submodule to prepare for fetching. You probably want to follow this up by invoking the 'update' action to fetch the submodule. |
+| `` b `` | View bulk submodule options | |
+| `` / `` | Filter the current view by text | |
+
+## Tags
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | Copy tag to clipboard | |
+| `` `` | Checkout | Checkout the selected tag as a detached HEAD. |
+| `` n `` | New tag | Create new tag from current commit. You'll be prompted to enter a tag name and optional description. |
+| `` d `` | Delete | View delete options for local/remote tag. |
+| `` P `` | Push tag | Push the selected tag to a remote. You'll be prompted to select a remote. |
+| `` g `` | Reset | View reset options (soft/mixed/hard) for resetting onto selected item. |
+| `` `` | Open external diff tool (git difftool) | |
+| `` 0 `` | Focus main view | |
+| `` `` | View commits | |
+| `` w `` | View worktree options | |
+| `` / `` | Filter the current view by text | |
+
+## Worktrees
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` n `` | New worktree | |
+| `` `` | Switch | Switch to the selected worktree. |
+| `` o `` | Open in editor | |
+| `` d `` | Remove | Remove the selected worktree. This will both delete the worktree's directory, as well as metadata about the worktree in the .git directory. |
+| `` / `` | Filter the current view by text | |
diff --git a/docs-master/keybindings/Keybindings_ja.md b/docs-master/keybindings/Keybindings_ja.md
new file mode 100644
index 000000000..79cf196fe
--- /dev/null
+++ b/docs-master/keybindings/Keybindings_ja.md
@@ -0,0 +1,414 @@
+_This file is auto-generated. To update, make the changes in the pkg/i18n directory and then run `go generate ./...` from the project root._
+
+# Lazygit キーバインディング
+
+_凡例：`＜c-b＞` はctrl+b、`＜a-b＞` はalt+b、`B` はshift+bを意味します_
+
+## グローバルキーバインド
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | 最近のリポジトリをチェックアウト | |
+| `` (fn+up/shift+k) `` | メインウィンドウを上にスクロール | |
+| `` (fn+down/shift+j) `` | メインウィンドウを下にスクロール | |
+| `` @ `` | コマンドログオプションを表示 | コマンドログのオプションを表示します（例：コマンドログの表示/非表示、コマンドログへのフォーカスなど）。 |
+| `` P `` | プッシュ | 現在のブランチを対応するアップストリームブランチにプッシュします。アップストリームが設定されていない場合、アップストリームブランチの設定を求められます。 |
+| `` p `` | プル | 現在のブランチのリモートから変更をプルします。アップストリームが設定されていない場合、アップストリームブランチの設定を求められます。 |
+| `` ) `` | リネーム検出の類似度しきい値を上げる | Increase the similarity threshold for a deletion and addition pair to be treated as a rename.
The default can be changed in the config file with the key 'git.renameSimilarityThreshold'. |
+| `` ( `` | リネーム検出の類似度しきい値を下げる | Decrease the similarity threshold for a deletion and addition pair to be treated as a rename.
The default can be changed in the config file with the key 'git.renameSimilarityThreshold'. |
+| `` } `` | 差分コンテキストサイズを増やす | Increase the amount of the context shown around changes in the diff view.
The default can be changed in the config file with the key 'git.diffContextSize'. |
+| `` { `` | 差分コンテキストサイズを減らす | Decrease the amount of the context shown around changes in the diff view.
The default can be changed in the config file with the key 'git.diffContextSize'. |
+| `` : `` | シェルコマンドを実行 | 実行するシェルコマンドを入力するプロンプトを表示します。 |
+| `` `` | カスタムパッチオプションを表示 | |
+| `` m `` | マージ/リベースオプションを表示 | 現在のマージ/リベースを中止/継続/スキップするオプションを表示します。 |
+| `` R `` | 更新 | Gitの状態を更新します（`git status`、`git branch`などをバックグラウンドで実行してパネルの内容を更新します）。これは`git fetch`を実行しません。 |
+| `` + `` | 次の画面モード（通常/半分/全画面） | |
+| `` _ `` | 前の画面モード | |
+| `` \| `` | Cycle pagers | Choose the next pager in the list of configured pagers |
+| `` `` | キャンセル | |
+| `` ? `` | キーバインディングメニューを開く | |
+| `` `` | フィルターオプションを表示 | コミットログのフィルタリングオプションを表示し、フィルタに一致するコミットのみを表示します。 |
+| `` W `` | 差分オプションを表示 | ２つのrefの差分に関連するオプションを表示します（例：選択したrefとの差分表示、差分を取るrefの入力、差分方向の反転など）。 |
+| `` `` | 差分オプションを表示 | ２つのrefの差分に関連するオプションを表示します（例：選択したrefとの差分表示、差分を取るrefの入力、差分方向の反転など）。 |
+| `` q `` | 終了 | |
+| `` `` | Suspend the application | |
+| `` `` | 空白表示の切り替え | Toggle whether or not whitespace changes are shown in the diff view.
The default can be changed in the config file with the key 'git.ignoreWhitespaceInDiffView'. |
+| `` z `` | 元に戻す | 最後のgitコマンドを元に戻すために実行するgitコマンドを決定するためにreflogが使用されます。これにはワーキングツリーへの変更は含まれません。コミットのみが考慮されます。 |
+| `` Z `` | やり直す | 最後のgitコマンドをやり直すために実行するgitコマンドを決定するためにreflogが使用されます。これにはワーキングツリーへの変更は含まれません。コミットのみが考慮されます。 |
+
+## リストパネルのナビゲーション
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` , `` | 前のページ | |
+| `` . `` | 次のページ | |
+| `` < () `` | 先頭にスクロール | |
+| `` > () `` | 末尾にスクロール | |
+| `` v `` | 範囲選択を切り替え | |
+| `` `` | 範囲選択を下に | |
+| `` `` | 範囲選択を上に | |
+| `` / `` | 現在のビューをテキストで検索 | |
+| `` H `` | 左にスクロール | |
+| `` L `` | 右にスクロール | |
+| `` ] `` | 次のタブ | |
+| `` [ `` | 前のタブ | |
+
+## Input prompt
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | 確認 | |
+| `` `` | 閉じる/キャンセル | |
+
+## コミット
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | コミットハッシュをクリップボードにコピー | |
+| `` `` | コピーされた（チェリーピックされた）コミットの選択をリセット | |
+| `` b `` | bisectオプションを表示 | |
+| `` s `` | スカッシュ | 選択したコミットをその下のコミットにスカッシュします。スカッシュとは複数のコミットを1つにまとめる操作です。選択したコミットのメッセージが下のコミットに追加されます。 |
+| `` f `` | フィックスアップ | 選択したコミットをその下のコミットにマージします。フィックスアップはスカッシュと似ていますが、選択したコミットのメッセージは破棄され、下のコミットのメッセージのみが保持されます。 |
+| `` r `` | メッセージ変更 | 選択したコミットのメッセージを変更します。 |
+| `` R `` | エディタでメッセージ変更 | |
+| `` d `` | 削除 | 選択したコミットを削除します。これはリベースを通じてブランチからコミットを削除します。コミットが後続のコミットが依存する変更を行っている場合、マージコンフリクトを解決する必要があるかもしれません。 |
+| `` e `` | 編集（対話型リベースを開始） | 選択したコミットを編集します。これを使用して、選択したコミットから対話型リベースを開始します。すでにリベース中の場合、これは選択したコミットを編集用にマークし、リベースを続行すると、リベースは選択したコミットで一時停止して変更を行えるようにします。 |
+| `` i `` | 対話的リベースを開始 | ブランチ上のコミットの対話的リベースを開始します。これには、HEADコミットから最初のマージコミットまたはメインブランチのコミットまでのすべてのコミットが含まれます。
選択したコミットから対話的リベースを開始したい場合は、代わりに `e` を押してください。 |
+| `` p `` | ピック | 選択したコミットをピックするようにマークします（リベース中）。これは、リベースを続行すると、コミットが保持されることを意味します。 |
+| `` F `` | fixupコミットを作成 | 選択したコミットに対する「fixup!」コミットを作成します。fixupコミットは、選択したコミットの修正用コミットです。後で、同じコミットで `S` を押すと、上記のすべてのfixupコミットが適用されます。 |
+| `` S `` | fixupコミットを適用 | すべての「fixup!」コミットを、選択したコミットの上部または現在のブランチ内のすべてをスカッシュします（autosquash）。 |
+| `` `` | コミットを1つ下に移動 | |
+| `` `` | コミットを1つ上に移動 | |
+| `` V `` | ペースト（チェリーピック） | |
+| `` B `` | リベース用のベースコミットとしてマーク | 次のリベース用のベースコミットを選択します。ブランチにリベースするとき、ベースコミットより上のコミットのみが持ち込まれます。これは `git rebase --onto` コマンドを使用します。 |
+| `` A `` | 修正 | ステージされた変更でコミットを修正します。選択したコミットがHEADコミットの場合、これは `git commit --amend` を実行します。それ以外の場合、コミットはリベースを通じて修正されます。 |
+| `` a `` | コミット属性を修正 | コミット作者の設定/リセットまたは共同作者の設定を行います。 |
+| `` t `` | リバート | 選択したコミットの変更を逆に適用する、リバートコミットを作成します。 |
+| `` T `` | コミットにタグを付ける | 選択したコミットを指すタグを新規作成します。タグ名とオプションの説明を入力するよう促されます。 |
+| `` `` | ログオプションを表示 | コミットログのオプションを表示します（例：並び順の変更、Gitグラフの非表示、Gitグラフ全体の表示）。 |
+| `` `` | チェックアウト（ブランチの切り替え） | 選択したコミットをデタッチドヘッド（特定のブランチに属さない状態）としてチェックアウトします。 |
+| `` y `` | コミット属性をクリップボードにコピー | コミット属性をクリップボードにコピーします（例：ハッシュ、URL、差分、メッセージ、作者）。 |
+| `` o `` | ブラウザでコミットを開く | |
+| `` n `` | コミットから新しいブランチを作成 | |
+| `` N `` | コミットを新しいブランチに移動 | Create a new branch and move the unpushed commits of the current branch to it. Useful if you meant to start new work and forgot to create a new branch first.
Note that this disregards the selection, the new branch is always created either from the main branch or stacked on top of the current branch (you get to choose which). |
+| `` g `` | リセット | 選択した項目へのリセットオプション（ソフト/ミックス/ハード）を表示します。各リセットタイプの詳細は次の通りです：
- ソフトリセット：変更を保持し、ステージされた状態にします
- ミックスリセット：変更を保持し、ステージされていない状態にします
- ハードリセット：すべての変更を破棄します |
+| `` C `` | コピー（チェリーピック） | コミットをコピーとしてマークします。ローカルコミットビューで `V` を押すと、コピーしたコミットをチェックアウトしたブランチにペースト（チェリーピック）できます。いつでも `` を押して選択をキャンセルできます。 |
+| `` `` | 外部差分ツールを開く（git difftool） | |
+| `` * `` | 現在のブランチのコミットを選択 | |
+| `` 0 `` | メインビューにフォーカス | |
+| `` `` | ファイルを表示 | |
+| `` w `` | ワークツリーオプションを表示 | |
+| `` / `` | 現在のビューをテキストで検索 | |
+
+## コミットファイル
+
+| Key | Action | Info |
+|-----|--------|-------------|
+| `` `` | パスをクリップボードにコピー | |
+| `` y `` | クリップボードにコピー | |
+| `` c `` | チェックアウト（ブランチの切り替え） | ファイルをチェックアウトします。これにより、作業ツリー内のファイルが選択したコミットのバージョンに置き換えられます。 |
+| `` d `` | 削除 | このコミットのこのファイルへの変更を破棄します。これはバックグラウンドで対話的なリベースを実行するため、後のコミットでもこのファイルが変更されている場合、マージコンフリクトが発生する可能性があります。 |
+| `` o `` | ファイルを開く | デフォルトのアプリケーションでファイルを開きます。 |
+| `` e `` | 編集 | 外部エディタでファイルを開きます。 |
+| `` `` | 外部差分ツールを開く（git difftool） | |
+| `` `` | パッチに含めるファイルを切り替え | ファイルがカスタムパッチに含まれるかどうかを切り替えます。https://github.com/jesseduffield/lazygit#rebase-magic-custom-patchesを参照してください。 |
+| `` a `` | すべてのファイルを切り替え | コミットのすべてのファイルをカスタムパッチに追加/削除します。https://github.com/jesseduffield/lazygit#rebase-magic-custom-patchesを参照してください。 |
+| `` `` | ファイルに入る / ディレクトリの折りたたみを切り替える | ファイルが選択されている場合、そのファイルに入ってカスタムパッチに個々の行を追加/削除できます。ディレクトリが選択されている場合、ディレクトリを切り替えます。 |
+| `` ` `` | ファイルツリービューを切り替え | Toggle file view between flat and tree layout. Flat layout shows all file paths in a single list, tree layout groups files by directory.