aaecd6cc40
This PR captures the code coverage from our unit and integration tests. At the moment it simply pushes the result to Codacy, a platform that assists with improving code health. Right now the focus is just getting visibility but I want to experiment with alerts on PRs when a PR causes a drop in code coverage. To be clear: I'm not a dogmatist about this: I have no aspirations to get to 100% code coverage, and I don't consider lines-of-code-covered to be a perfect metric, but it is a pretty good heuristic for how extensive your tests are. The good news is that our coverage is actually pretty good which was a surprise to me! As a conflict of interest statement: I'm in Codacy's 'Pioneers' program which provides funding and mentorship, and part of the arrangement is to use Codacy's tooling on lazygit. This is something I'd have been happy to explore even without being part of the program, and just like with any other static analysis tool, we can tweak it to fit our use case and values. ## How we're capturing code coverage This deserves its own section. Basically when you build the lazygit binary you can specify that you want the binary to capture coverage information when it runs. Then, if you run the binary with a GOCOVERDIR env var, it will write coverage information to that directory before exiting. It's a similar story with unit tests except with those you just specify the directory inline via `-test.gocoverdir`. We run both unit tests and integration tests separately in CI, _and_ we run them parallel with different OS's and git versions. So I've got each step uploading the coverage files as an artefact, and then in a separate step we combine all the artefacts together and generate a combined coverage file, which we then upload to codacy (but in future we can do other things with it like warn in a PR if code coverage decreases too much). Another caveat is that when running integration tests, not only do we want to obtain code coverage from code executed by the test binary, we also want to obtain code coverage from code executed by the test runner. Otherwise, for each integration test you add, the setup code (which is run by the test runner, not the test binary) will be considered un-covered and for a large setup step it may appear that your PR _decreases_ coverage on net. Go doesn't easily let you exclude directories from coverage reports so it's better to just track the coverage from both the runner and the binary. The binary expects a GOCOVERDIR env var but the test runner expects a test.gocoverdir positional arg and if you pass the positional arg it will internally overwrite GOCOVERDIR to some random temp directory and if you then pass that to the test binary, it doesn't seem to actually write to it by the time the test finishes. So to get around that we're using LAZYGIT_GOCOVERDIR and then within the test runner we're mapping that to GOCOVERDIR before running the test binary. So they both end up writing to the same directory. Coverage data files are named to avoid conflicts, including something unique to the process, so we don't need to worry about name collisions between the test runner and the test binary's coverage files. We then merge the files together purely for the sake of having fewer artefacts to upload. ## Misc Initially I was able to have all the instances of '/tmp/code_coverage' confined to the ci.yml which was good because it was all in one place but now it's spread across ci.yml and scripts/run_integration_tests.sh and I don't feel great about that but can't think of a way to make it cleaner. I believe there's a use case for running scripts/run_integration_tests.sh outside of CI (so that you can run tests against older git versions locally) so I've made it that unless you pass the LAZYGIT_GOCOVERDIR env var to that script, it skips all the code coverage stuff. On a separate note: it seems that Go's coverage report is based on percentage of statements executed, whereas codacy cares more about lines of code executed, so codacy reports a higher percentage (e.g. 82%) than Go's own coverage report (74%).
A simple terminal UI for git commands
Sponsors
Maintenance of this project is made possible by all the contributors and sponsors. If you'd like to sponsor this project and have your avatar or company logo appear below click here. 💙
Elevator Pitch
Rant time: You've heard it before, git is powerful, but what good is that power when everything is so damn hard to do? Interactive rebasing requires you to edit a goddamn TODO file in your editor? Are you kidding me? To stage part of a file you need to use a command line program to step through each hunk and if a hunk can't be split down any further but contains code you don't want to stage, you have to edit an arcane patch file by hand? Are you KIDDING me?! Sometimes you get asked to stash your changes when switching branches only to realise that after you switch and unstash that there weren't even any conflicts and it would have been fine to just checkout the branch directly? YOU HAVE GOT TO BE KIDDING ME!
If you're a mere mortal like me and you're tired of hearing how powerful git is when in your daily life it's a powerful pain in your ass, lazygit might be for you.
Table of contents
- Sponsors
- Elevator Pitch
- Table of contents
- Features
- Tutorials
- Installation
- Usage
- Configuration
- Contributing
- Donate
- FAQ
- Shameless Plug
- Alternatives
Lazygit is not my fulltime job but it is a hefty part time job so if you want to support the project please consider sponsoring me
Features
Stage individual lines
Press space on the selected line to stage it, or press v to start selecting a range of lines. You can also press a to select the entirety of the current hunk.
Interactive Rebase
Press e on a commit to start an interactive rebase on it: causing all above commits to become part of the TODO file. Then squash (s), fixup (f), drop (d), edit (e), move up (ctrl+i) or move down (ctrl+j) any of TODO commits, before continuing the rebase by bringing up the rebase options menu with m and then selecting continue. You can also perform any these actions as a once-off (e.g. pressing s on a commit to squash it) without explicitly starting a rebase.
Cherry-pick
Press c on a commit to copy it and press v to paste (cherry-pick) it.
Bisect
Press b in the commits view to mark a commit as good/bad in order to begin a git bisect.
Nuke the working tree
For when you really want to just get rid of anything that shows up when you run git status (and yes that includes dirty submodules) kidpix style, press shift+d to bring up the reset options menu and then select the 'nuke' option.
Amend an old commit
Pressing shift+a on any commit will amend that commit with the currently staged changes (running an interactive rebase in the background).
Filter
You can filter a view with /. Here we filter down our branches view and then hit enter to view its commits.
Invoke a custom command
Lazygit has a very flexible custom command system. In this example a custom command is defined which emulates the built-in branch checkout action.
Worktrees
You can create worktrees to have multiple branches going at once without the need for stashing or creating WIP commits when switching between them. Press w in the branches view to create a worktree from the selected branch and switch to it.
Rebase magic (custom patches)
You can build a custom patch from an old commit and then remove the patch from the commit, split out a new commit, apply the patch in reverse to the index, and more.
In this example we have a redundant comment that we want to remove from an old commit. We hit <enter> on the commit to view its files, then <enter> on a file to focus the patch, then <space> to add the comment line to our custom patch, and then ctrl+p to view the custom patch options; selecting to remove the patch from the current commit.
Learn more in the Rebase magic Youtube tutorial.
Rebase from marked base commit
Say you're on a feature branch that was itself branched off of the develop branch, and you've decided you'd rather be branching off the master branch. You need a way to rebase only the commits from your feature branch. In this demo we check to see which was the last commit on the develop branch, then press shift+b to mark that commit as our base commit, then press r on the master branch to rebase onto it, only bringing across the commits from our feature branch. Then we push our changes with shift+p.
Undo
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.
Commit graph
When viewing the commit graph in an enlarged window (use + and _ to cycle window sizes), the commit graph is shown. Colours correspond to the commit authors, and as you navigate down the graph, the parent commits of the selected commit are highlighted.
Compare two commits
If you press shift+w on a commit (or branch/ref) a menu will open that allows you to mark that commit so that any other commit you select will be diffed against it. Once you've selected the second commit, you'll see the diff in the main view and if you press <enter> you'll see the files of the diff. You can press shift+w to view the diff menu again to see options like reversing the diff direction or exiting diff mode. You can also exit diff mode by pressing <escape>.
Tutorials
Installation
Most of the above packages are maintained by third parties so be sure to vet them yourself and confirm that the maintainer is a trustworthy looking person who attends local sports games and gives back to their communities with barbeque fundraisers etc
Binary Releases
For Windows, Mac OS(10.12+) or Linux, you can download a binary release here.
Homebrew
Normally the lazygit formula can be found in the Homebrew core but we suggest you tap our formula to get the frequently updated one. It works with Linux, too.
Tap:
brew install jesseduffield/lazygit/lazygit
Core:
brew install lazygit
MacPorts
Latest version built from github releases. Tap:
sudo port install lazygit
Void Linux
Packages for Void Linux are available in the distro repo
They follow upstream latest releases
sudo xbps-install -S lazygit
Scoop (Windows)
You can install lazygit using scoop. It's in the extras bucket:
# Add the extras bucket
scoop bucket add extras
# Install lazygit
scoop install lazygit
Arch Linux
Packages for Arch Linux are available via pacman and AUR (Arch User Repository).
There are two packages. The stable one which is built with the latest release and the git version which builds from the most recent commit.
- Stable:
sudo pacman -S lazygit - Development: https://aur.archlinux.org/packages/lazygit-git/
Instruction of how to install AUR content can be found here: https://wiki.archlinux.org/index.php/Arch_User_Repository
Fedora and RHEL
Packages for Fedora/RHEL and CentOS Stream are available via Copr (Cool Other Package Repo).
sudo dnf copr enable atim/lazygit -y
sudo dnf install lazygit
Solus Linux
sudo eopkg install lazygit
Ubuntu
LAZYGIT_VERSION=$(curl -s "https://api.github.com/repos/jesseduffield/lazygit/releases/latest" | grep -Po '"tag_name": "v\K[^"]*')
curl -Lo lazygit.tar.gz "https://github.com/jesseduffield/lazygit/releases/latest/download/lazygit_${LAZYGIT_VERSION}_Linux_x86_64.tar.gz"
tar xf lazygit.tar.gz lazygit
sudo install lazygit /usr/local/bin
Verify the correct installation of lazygit:
lazygit --version
Funtoo Linux
Funtoo Linux has an autogenerated lazygit package in dev-kit:
sudo emerge dev-vcs/lazygit
Gentoo Linux
Lazygit is not (yet) in main Gentoo portage, however an ebuild is available in cova overlay
You can either add the overlay to your system and install lazygit as usual:
sudo eselect repository enable cova
sudo emaint sync -r cova
sudo emerge dev-vcs/lazygit
Or you can download the ebuild and install it manually; please consider the example below just as a suggestion to be adapted to your system.
su
LAZYGIT_VERSION="0.39.3" # Replace with the version you want from cova-overlay
cd /usr/overlay/dev-vcs/ # Replace your overlay path
mkdir lazygit
cd lazygit
curl -O https://raw.githubusercontent.com/cova-fe/cova-overlay/main/dev-vcs/lazygit/lazygit-${LAZYGIT_VERSION}.ebuild
ebuild lazygit-${LAZYGIT_VERSION}.ebuild manifest
emerge lazygit
openSUSE
The lazygit package is currently built in devel:languages:go/lazygit.
To install lazygit on openSUSE Tumbleweed run:
sudo zypper ar https://download.opensuse.org/repositories/devel:/languages:/go/openSUSE_Factory/devel:languages:go.repo
sudo zypper ref && sudo zypper in lazygit
To install lazygit on openSUSE Leap run:
source /etc/os-release
sudo zypper ar https://download.opensuse.org/repositories/devel:/languages:/go/$VERSION_ID/devel:languages:go.repo
sudo zypper ref && sudo zypper in lazygit
FreeBSD
pkg install lazygit
Termux
apt install lazygit
Conda
Released versions are available for different platforms, see https://anaconda.org/conda-forge/lazygit
conda install -c conda-forge lazygit
Go
go install github.com/jesseduffield/lazygit@latest
Please note:
If you get an error claiming that lazygit cannot be found or is not defined, you
may need to add ~/go/bin to your $PATH (MacOS/Linux), or %HOME%\go\bin
(Windows). Not to be mistaken for C:\Go\bin (which is for Go's own binaries,
not apps like lazygit).
Chocolatey (Windows)
You can install lazygit using Chocolatey:
choco install lazygit
Winget (Windows 10 1709 or later)
You can install lazygit using the winget command in the Windows Terminal with the following command:
winget install -e --id=JesseDuffield.lazygit
Manual
You'll need to install Go
git clone https://github.com/jesseduffield/lazygit.git
cd lazygit
go install
You can also use go run main.go to compile and run in one go (pun definitely intended)
Usage
Call lazygit in your terminal inside a git repository.
$ lazygit
If you want, you can
also add an alias for this with echo "alias lg='lazygit'" >> ~/.zshrc (or
whichever rc file you're using).
Keybindings
You can check out the list of keybindings here.
Changing Directory On Exit
If you change repos in lazygit and want your shell to change directory into that repo on exiting lazygit, add this to your ~/.zshrc (or other rc file):
lg()
{
export LAZYGIT_NEW_DIR_FILE=~/.lazygit/newdir
lazygit "$@"
if [ -f $LAZYGIT_NEW_DIR_FILE ]; then
cd "$(cat $LAZYGIT_NEW_DIR_FILE)"
rm -f $LAZYGIT_NEW_DIR_FILE > /dev/null
fi
}
Then source ~/.zshrc and from now on when you call lg and exit you'll switch directories to whatever you were in inside lazygit. To override this behaviour you can exit using shift+Q rather than just q.
Undo/Redo
See the docs
Configuration
Check out the configuration docs.
Custom Pagers
See the docs
Custom Commands
If lazygit is missing a feature, there's a good chance you can implement it yourself with a custom command!
See the docs
Git flow support
Lazygit supports Gitflow if you have it installed. To understand how the Gitflow model works check out Vincent Driessen's original post explaining it. To view Gitflow options from within Lazygit, press i from within the branches view.
Contributing
We love your input! Please check out the contributing guide. For contributor discussion about things not better discussed here in the repo, join the discord channel
Check out this video walking through the creation of a small feature in lazygit if you want an idea of where to get started.
Debugging Locally
Run lazygit --debug in one terminal tab and lazygit --logs in another to view the program and its log output side by side
Donate
If you would like to support the development of lazygit, consider sponsoring me (github is matching all donations dollar-for-dollar for 12 months)
FAQ
What do the commit colors represent?
- Green: the commit is included in the master branch
- Yellow: the commit is not included in the master branch
- Red: the commit has not been pushed to the upstream branch
Shameless Plug
If you want to see what I (Jesse) am up to in terms of development, follow me on twitter or check out my blog
Alternatives
If you find that lazygit doesn't quite satisfy your requirements, these may be a better fit: