We use an interactive shell so that users can use their custom shell aliases in
lazygit's shell prompt, which is convenient; however, this only really works for
shells like bash or zsh. We know it doesn't work for fish or nushell (because
these use different names for the $? variable); so use an interactive shell only
if the user's shell is either bash or zsh.
- **PR Description**
I don't know what was I thinking when making #3049, because Micro does
not actually support `--` as delimiter between options and files. As
such, when trying to edit files with `micro` set as editor, an empty
file named `--` would be open first.
This PR fixes this by explicitly defining a preset for `micro`. I've
double-tested it to make sure that it doesn't behave wierdly any more :D
- **PR Description**
The other day, I was cherry-picking a selection of commits and was
annoyed that the "Are you sure..." prompt did not include the actual
number of commits I was about to cherry-pick.
I failed to realize the number of copied commits is displayed at the
bottom right until going to update the integration tests. I personally
think it's still nice to display the number in the actual confirmation
prompt but feel free to close this PR if the change is unwanted.
- **PR Description**
There are two ways to jump to the editor on a specific line: pressing `e` in the
staging or patch building panels, or clicking on a hyperlink in a delta diff. In
both cases, this works perfectly in the unstaged changes view, but in other
views (either staged changes, or an older commit) it can often jump to the wrong
line; this happens when there are further changes to the file being viewed in
later commits or in unstaged changes.
This commit fixes this so that you end up on the right line in these cases.
There are two ways to jump to the editor on a specific line: pressing `e` in the
staging or patch building panels, or clicking on a hyperlink in a delta diff. In
both cases, this works perfectly in the unstaged changes view, but in other
views (either staged changes, or an older commit) it can often jump to the wrong
line; this happens when there are further changes to the file being viewed in
later commits or in unstaged changes.
This commit fixes this so that you end up on the right line in these cases.
When pressing `e` on line 5 in a diff of an older commit, we expect it to take
us to line 5 in that file. But we end up on line 2, because the file had further
changes both in newer commits, and in the unstaged changes of the working copy.
- **PR Description**
This updates gocui to include
https://github.com/jesseduffield/gocui/pull/68 and
https://github.com/jesseduffield/gocui/pull/69, which changes views to
not have an extra blank line at the end when content ending in a newline
character is written to them. This makes text views more consistent with
list views, which don't have a blank line after the last list entry
either.
This updates gocui to include https://github.com/jesseduffield/gocui/pull/68 and
https://github.com/jesseduffield/gocui/pull/69, which changes views to not have
an extra blank line at the end when content ending in a newline character is
written to them. This makes text views more consistent with list views, which
don't have a blank line after the last list entry either.
- **PR Description**
Resetting to the upstream branch was broken when the remote branch has a
different name than the local branch.
Rebasing onto the upstream worked fine, but also displayed the wrong
branch name in the menu.
Fixes#4148.
The easiest way to do that is to rename the local branch after pushing.
This shows various levels of brokenness for the reset and rebase to upstream
commands: both menu entries display the wrong upstream branch name in the menu
(the local one rather than the remote one); executing the rebase command works
correctly though, the rebase command uses the right branch name. Resetting
fails, though.
We'll fix this in the next commit.
- **PR Description**
It wasn't really obvious how to commit when the focus is in the commit
description view, since pressing enter inserts a newline there. To
improve this, show the `<a-enter>` keybinding at the bottom of the
description view when it is focused.
Fixes#4134.
This makes it possible to "silently" disable a keybinding. The effect is the
same as putting the check in the handler and returning nil from there, except
that doing it this way also hides it from the bottom line if DisplayOnScreen is
true.
It should have been half-screen from the get-go. I think I just used
full-screen to make demos look nicer. Now that we have a CLI arg for the
screen mode we can make use of that in the demos.
Introduce a new "screen-mode" command line argument that allows a user
to specify which screen mode (normal, half or full) Lazygit should use
when it runs.
This argument will take precedence over a default Window Size specified
in user config.
- **PR Description**
Lazygit already accepts to customize UI colors using HEX values but the
color of the icons still were using C256 notation, this PR makes the
change to use HEX values. Not sure if there is a special reason to not
make the change.
You can create the available files with:
```shell
touch _gvimrc _vimrc bin brewfile bspwmrc build build.gradle build.zig.zon cantorrc Cargo.lock Cargo.toml checkhealth cmakelists.txt CODE-OF-CONDUCT.md CODE_OF_CONDUCT CODE_OF_CONDUCT.md COMMIT_EDITMSG commit_editmsg commitlint.config.js commitlint.config.ts compose.yaml compose.yml config containerfile copying copying.lesser docker-compose.yaml docker-compose.yml dockerfile Dockerfile ds_store eslint.config.cjs eslint.config.js eslint.config.mjs eslint.config.ts ext_typoscript_setup.txt favicon.ico fn fp-info-cache fp-lib-table FreeCAD.conf gemfile$ gitignore_global gnumakefile GNUmakefile go.mod go.sum go.work gradle gradle-wrapper.properties gradle.properties gradlew gruntfile.babel.js gruntfile.coffee gruntfile.js gruntfile.ls gruntfile.ts gtkrc gulpfile.babel.js gulpfile.coffee gulpfile.js gulpfile.ls gulpfile.ts hidden hypridle.conf hyprland.conf hyprlock.conf hyprpaper.conf i3blocks.conf i3status.conf include ionic.config.json justfile kalgebrarc kdeglobals kdenlive-layoutsrc kdenliverc kritadisplayrc kritarc lib LICENSE LICENSE.md localized lxde-rc.xml lxqt.conf Makefile mix.lock mpv.conf node_modules npmignore nuxt.config.cjs nuxt.config.js nuxt.config.mjs nuxt.config.ts package-lock.json package.json PKGBUILD platformio.ini pom.xml prettier.config.cjs prettier.config.js prettier.config.mjs prettier.config.ts PrusaSlicer.ini PrusaSlicerGcodeViewer.ini py.typed QtProject.conf R robots.txt rubydoc SECURITY SECURITY.md settings.gradle strings svelte.config.js sxhkdrc sym-lib-table tailwind.config.js tailwind.config.mjs tailwind.config.ts tmux.conf tmux.conf.local tsconfig.json unlicense vagrantfile$ vlcrc webpack weston.ini workspace xmobarrc xmobarrc.hs xmonad.hs xorg.conf xsettingsd.conf yarn.lock
```
and
```shell
touch f.{cmake,3gp,3mf,7z,a,aac,ai,aif,aiff,android,ape,apk,app,apple,applescript,asc,ass,astro,avi,avif,avro,awk,azcli,bak,bash,bash_history,bash_pro,bashrc,bat,bats,bazel,bib,bicep,bicepparam,bladephp,blend,blp,bmp,brep,bz,bz2,bz3,bzl,c,c++,cab,cache,cast,cbl,cc,ccm,cfg,cjs,class,clj,cljc,cljd,cljs,cls,cmake,cmd,cob,cobol,coffee,conf,configru,cp,cpio,cpp,cppm,cpy,cr,crdownload,cs,csh,cshtml,cson,csproj,css,csv,csx,cts,cu,cue,cuh,cxx,cxxm,d,dts,dart,db,dconf,deb,desktop,diff,djvu,dll,doc,docx,dot,download,drl,dropbox,ds_store,DS_store,dump,dwg,dxf,ebook,ebuild,editorconfig,edn,eex,ejs,el,elc,elf,elm,eln,env,eot,epp,epub,erb,erl,ex,exe,exs,f#,f3d,f90,fbx,fcbak,fcmacro,fcmat,fcparam,fcscript,fcstd,fcstd1,fctb,fctl,fdmdownload,fish,flac,flc,flf,flv,fnl,font,fs,fsi,fsscript,fsx,gcode,gd,gdoc,gem,gem,gemspec,gform,gif,git,glb,gnumake,go,godot,gql,gradle,graphql,gresource,groovy,gsheet,gslides,guard,gv,gz,h,haml,hbs,hc,heex,hex,hh,hpp,hrl,hs,htm,html,huff,hurl,hx,hxx,ical,icalendar,ico,ics,ifb,ifc,ige,iges,igs,image,img,iml,import,info,ini,ino,ipynb,iso,ixx,j2c,j2k,jad,jar,java,jfi,jfif,jif,jl,jmd,jp2,jpe,jpeg,jpg,jpx,js,json,json5,jsonc,jsx,jwmrc,jxl,kbx,kdb,kdbx,kdenlive,kdenlivetitle,kicad_dru,kicad_mod,kicad_pcb,kicad_prl,kicad_pro,kicad_sch,kicad_sym,kicad_wks,ko,kpp,kra,krz,ksh,kt,kts,latex,lck,leex,less,lff,lhs,license,liquid,localized,lock,log,lrc,lua,luac,luau,lz,lz4,lzh,lzma,lzo,m,m3u,m3u8,m4a,m4v,magnet,make,markdown,material,md,md5,mdx,mint,mjs,mk,mkd,mkv,ml,mli,mm,mo,mobi,mojo,mov,mp3,mp4,mpp,msf,msi,mts,mustache,nfo,nim,nix,node,npmignore,nswag,nu,o,obj,odp,ods,odt,ogg,ogv,opus,org,otf,out,part,patch,pck,pdf,php,pl,pls,ply,pm,png,po,pot,pp,ppt,pptx,prisma,pro,proc,properties,ps1,psb,psd,psd1,psm1,pub,pxd,pxi,pxm,py,pyc,pyd,pyi,pyo,pyw,pyx,qm,qml,qrc,qss,query,r,rake,rake,rar,razor,rb,rdata,rdb,rdoc,rds,readme,res,resi,rlib,rmd,rpm,rproj,rs,rspec,rspec_parallel,rspec_status,rss,rtf,ru,rubydoc,sass,sbt,sc,scad,scala,scm,scss,sh,sha1,sha224,sha256,sha384,sha512,shell,sig,signature,skp,sldasm,sldprt,slim,sln,slvs,sml,so,sol,specjs,specjsx,spects,spectsx,sql,sqlite,sqlite3,srt,ssa,ste,step,stl,stp,strings,sty,styl,stylus,sub,sublime,suo,sv,svelte,svg,svh,swift,t,tar,taz,tbc,tbz,tbz2,tcl,templ,terminal,testjs,testjsx,testts,testtsx,tex,tf,tfvars,tgz,tiff,tlz,tmux,toml,torrent,tres,ts,tscn,tsconfig,tsv,tsx,ttf,twig,txt,txz,typoscript,tz,tzo,ui,v,vala,vh,vhd,vhdl,video,vim,vsh,vsix,vue,war,wasm,wav,webm,webmanifest,webp,webpack,windows,wma,woff,woff2,wrl,wrz,wv,wvc,x,xaml,xcf,xcplayground,xcstrings,xhtml,xls,xlsx,xm,xml,xpi,xul,xz,yaml,yml,zig,zip,zsh,zsh-theme,zshrc,zst,strings}
```
to check the new colors.
Some icons could have be changed because I compared againa
nvim-web-devicons file.
Let me know if you want to change some icon or color.
**Edit**: I added 2 new commits that use glyphs from Nerd Fonts 3.3.0
---
- **Please check if the PR fulfills these requirements**
* [x] Cheatsheets are up-to-date (run `go generate ./...`)
* [X] Code has been formatted (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting))
* [ ] Tests have been added/updated (see
[here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md)
for the integration test guide)
* [x] Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [ ] If a new UserConfig entry was added, make sure it can be
hot-reloaded (see
[here](https://github.com/jesseduffield/lazygit/blob/master/docs/dev/Codebase_Guide.md#using-userconfig))
* [x] Docs have been updated if necessary
* [X] You've read through your own file changes for silly mistakes etc
<!--
Be sure to name your PR with an imperative e.g. 'Add worktrees view'
see https://github.com/jesseduffield/lazygit/releases/tag/v0.40.0 for
examples
-->
- **PR Description**
When the user checks out a commit which has a local branch ref attached
to it, they can select between checking out the branch or checking out
the commit as detached head. If no local branch is attached to the
commit, the behavior is like before: They are asked to confirm, if they
want to checkout the commit as detached head.
Requested in #4115.
Note: I tried also to consider remote branches, but because I wasn't
able to correlate remote branches to their commits, I deferred it and
leave it open for later improvement.
When the user checks out a commit which has a local branch ref attached
to it, they can select between checking out the branch or checking out
the commit as detached head.
- **PR Description**
configuration.nix is a file, and most files in the README.md are
stylized as code blocks. `environment.systemPackages` is actually just a
code block, and should be stylized as such.
configuration.nix is a file, and most files in the README.md are
stylized as code blocks. `environment.systemPackages` is actually just a
code block, and should be stylized as such
I want to spell out the design principles behind Lazygit so that our
priorities are clear and it's easier to make UX decisions (especially
for early contributors).
It's not possible to codify this in a way that will resolve all disputes
but I think it's worthwhile to enumerate some of the things that keep
coming up in our discussions about X or Y feature.
This is a very rough draft (effectively a brain-dump). So I expect
plenty of feedback :)
CC @stefanhaller @karimkhaleel @mark2185 @afhoffman @AzraelSec
- **Please check if the PR fulfills these requirements**
* [ ] Docs have been updated if necessary
In 5a3049485c we changed the execution of shell commands to use an interactive
shell (-i), because this allows users to use aliases or shell functions, which
is a nice convenience.
Since then, however, many users have reported problems with lazygit not coming
back to the foreground after executing a shell command. Some users report that
appending "; exit" to the end of the command line solves this. I don't really
understand what the cause of this problem was, or why appending "; exit" solves
it, but if it helps, let's do it.
- **PR Description**
Sometimes we populate the commit message panel with a pre-created commit
message. The two cases where this happens is:
- you type `w` to commit, in which case we put the skipHookPrefix in the subject
- you have a commitPrefix pattern, in which case we match it against the branch
name and populate the subject with the replacement string if it matches
In either case, if you have a preserved commit message, we use that.
Now, when you use either of these and then cancel, we preserve that initial,
unchanged message and reuse it the next time you commit. This has two problems:
it strips spaces, which is a problem for the commitPrefix patterns, which often
end with a space. And also, when you change your config to experiment with
commitPrefix patterns, the change seemingly doesn't take effect, which can be
very confusing.
To fix both of these problems, only preserve the commit message when it is not
identical to the initial message.
- **Please check if the PR fulfills these requirements**
* [x] Cheatsheets are up-to-date (run `go generate ./...`)
* [x] Code has been formatted (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting))
* [x] Tests have been added/updated (see [here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md) for the integration test guide)
* [ ] Text is internationalised (see [here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [ ] If a new UserConfig entry was added, make sure it can be hot-reloaded (see [here](https://github.com/jesseduffield/lazygit/blob/master/docs/dev/Codebase_Guide.md#using-userconfig))
* [ ] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
Sometimes we populate the commit message panel with a pre-created commit
message. The two cases where this happens is:
- you type `w` to commit, in which case we put the skipHookPrefix in the subject
- you have a commitPrefix pattern, in which case we match it against the branch
name and populate the subject with the replacement string if it matches
In either case, if you have a preserved commit message, we use that.
Now, when you use either of these and then cancel, we preserve that initial,
unchanged message and reuse it the next time you commit. This has two problems:
it strips spaces, which is a problem for the commitPrefix patterns, which often
end with a space. And also, when you change your config to experiment with
commitPrefix patterns, the change seemingly doesn't take effect, which can be
very confusing.
To fix both of these problems, only preserve the commit message when it is not
identical to the initial message.
- **PR Description**
Add a user config (on by default) to turn on line wrapping in the
staging view (and custom patch building view).
Fixes#3558.
This is a bit of a longer PR because I had to fix a bunch of things to
make this possible, and because it takes much more than just turning on
`Wrap` on the staging view.
Usually when I make changes to gocui I include them in the lazygit PR
for easier review; this time, however, the changes required touching
gocui's tests, which are not included in our vendored copy, so I made a
[PR in gocui](https://github.com/jesseduffield/gocui/pull/67) to be
reviewed there, and only included the squashed changes here.
Hot-reloading of the new user config is not perfect: if the staging view
is focused, you need to escape out of it and enter it again for the
change to take affect. I wasn't sure it's worth adding code to fix this.
As for tests: I didn't find a way to add an integration test for this,
as the view geometry is not fixed when you run them locally. But I
didn't look into this very deeply.
- **Please check if the PR fulfills these requirements**
* [x] Cheatsheets are up-to-date (run `go generate ./...`)
* [x] Code has been formatted (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting))
* [x] Tests have been added/updated (see
[here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md)
for the integration test guide)
* [x] Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [x] If a new UserConfig entry was added, make sure it can be
hot-reloaded (see
[here](https://github.com/jesseduffield/lazygit/blob/master/docs/dev/Codebase_Guide.md#using-userconfig))
* [ ] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
This makes it so that when the staging view is resized, we keep the same patch
line selected (as opposed to the same view line, which may correspond to a
different patch line after resizing). It doesn't seem like a terribly important
feature for resizing the window, but it is essential when initially entering the
staging view: we select the first line of the first hunk in this case, but we do
that before layout runs. At layout time the view is then split into
unstaged/staged changes, and if this split is horizontal, the view gets narrower
and may be wrapped in a different way. With this commit we ensure that the first
line of the first hunk is still selected after that.
So far, lines in the view corresponded 1:1 to lines in the patch. Once we turn
on wrapping for the staging view (which we don't do yet), this is no longer
true, so we need to convert from view lines to patch lines or vice versa all
over the place.
This doesn't improve the code much in the current state, but we'll add some more
code to this helper function in the next commit, which makes it worth it.
We haven't needed this before since we were only using the function for text in
confirmations and menus, which is unlikely to contain tabs. We are going to use
it for patches in the staging view though, which often do.
to make it more generally usable by clients other than ConfirmationHelper, which
we will do later in this branch. Rename it to WrapViewLinesToWidth while we're
at it.
Add tests; in particular, add a sanity check that we wrap lines the same way as
gocui does. The tests that are added here are the same ones as in gocui for its
lineWrap function, but we'll extend them a bit in later commits in this branch.
This is also what we do in the staging controller, and it makes it so that when
you exit the patch building view and then enter it again (for another file, or
the same one) we select the first hunk again.
- **PR Description**
When moving the first commit of the second branch in a stack down by one
(across the branch head of the first branch), the current behavior is
broken: we move the commit only past the update-ref todo of branch1,
which means the order of commits stays the same and only the branch head
icon moves up by one. However, we move the selection down by one, so the
wrong commit is selected now. This is especially bad if you type a bunch
of ctrl-j quickly in a row, because now you are moving the wrong commit.
There would be two possible ways to fix this:
1) keep the moving behavior the same, but don't change the selection
2) change the behavior so that we move the commit not only past the
update-ref, but also past the next real commit.
You could argue that 1) is the more desirable fix, as it gives you more
control over where exactly the moved commit goes; however, it is much
trickier to implement, so we go with 2) for now. If users need more
fine-grained control, they can always enter an interactive rebase first.
While we're at it, also fix moving a commit across an exec todo in an
interactive rebase, which is currently broken (it moves the commit one
too far).
Fixes#4040.
- **Please check if the PR fulfills these requirements**
* [x] Cheatsheets are up-to-date (run `go generate ./...`)
* [x] Code has been formatted (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting))
* [x] Tests have been added/updated (see
[here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md)
for the integration test guide)
* [ ] Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [ ] If a new UserConfig entry was added, make sure it can be
hot-reloaded (see
[here](https://github.com/jesseduffield/lazygit/blob/master/docs/dev/Codebase_Guide.md#using-userconfig))
* [ ] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
The test demonstrates that the behavior is undesirable right now: we move the
commit only past the update-ref todo of branch1, which means the order of
commits stays the same and only the branch head icon moves up by one. However,
we move the selection down by one, so the wrong commit is selected now. This is
especially bad if you type a bunch of ctrl-j quickly in a row, because now you
are moving the wrong commit.
There are two possible ways to fix this:
1) keep the moving behavior the same, but don't change the selection
2) change the behavior so that we move the commit not only past the update-ref,
but also past the next real commit.
You could argue that 1) is the more desirable fix, as it gives you more control
over where exactly the moved commit goes; however, it is much trickier to
implement, so we go with 2) for now (and that's what the commented-out
"EXPECTED" section documents here). If users need more fine-grained control,
they can always enter an interactive rebase first.
For non-merge commits we change "pick" to "drop" when we delete them. We do this
so that we can use the same code for dropping a commit no matter whether we are
in an interactive rebase or not. (If we aren't, we could just as well delete the
pick line from the todo list instead of setting it to "drop", but if we are, it
is better to keep the line around so that the user can change it back to "pick"
if they change their mind.)
However, merge commits can't be changed to "drop", so we have to delete them
from the todo file. We add a new daemon instruction that does this.
We still don't allow deleting a merge commit from within an interactive rebase.
The reason is that we don't show the "label" and "reset" todos in lazygit, so
deleting a merge commit would leave the commits from the branch that is being
merged in the list as "pick" commits, with no indication that they are going to
be dropped because they are on a different branch, and the merge commit that
would have brought them in is gone. This could be very confusing.
One of the comments we are deleting here said:
// Comparing just the hash is not enough; we need to compare both the
// action and the hash, as the hash could appear multiple times (e.g. in a
// pick and later in a merge).
I don't remember what I was thinking when I wrote this code, but it's nonsense
of course. Maybe I was thinking that the hash that appears in a "merge" todo
would be the hash of the commit that is being merged in (which would then
actually appear in an earlier pick), but it isn't, it's the hash of the merge
commit itself (so that the rebase can reuse its commit message). Which means
that hashes are unique, no need to compare the action.
So far it didn't have to handle the case where one hash is empty and the other
isn't, but in the next commit we need that, so let's handle that case correctly.
There's enough logic in the function now that it's worth covering it with tests.
Not much of a change in behavior, because moving merge commits was already not
possible. However, it failed with a cryptic error message ("Todo fa1afe1 not
found in git-rebase-todo"), so disable it properly instead.
When enabled, it adds "+n -m" after each file in the Files panel to show how
many lines were added and deleted, as with `git diff --numstat` on the command
line.
- **PR Description**
This PR fixes to issues with the current implementation of the OSConfig
for WSL:
**File explorer**
When using the file explorer from WSL, for instance by pressing "o" in
the "Files" menu, the explorer always opens on the default landing page.
This is caused by the filepath being expressed in WSL format instead of
the expected Windows format. For instance:
- "/home/myuser/path/to/my/file" should be
"\\wsl$\MyDistroName\home\myuser\path\to\my\file"
- "/mnt/c/path/to/my/file" should be "C:\path\to\my\file"
There's a utility to do that in WSL, `wslpath`. We use it in the Open to
format the filename before passing it to the Powershell command
**Link URLs**
Opening links containing ampersands inside lazygit (a pull-request
creation page in BitBucket Server, for instance) returns the following
Powershell error:
> The ampersand (&) character is not allowed. The & operator is reserved
> for future use; wrap an ampersand in double quotation marks ("&") to
> pass it as part of a string.
We fix it by enclosing the URL in single quotes.
**Notes on this PR**
This is my first PR on this repo, please tell me if something is needed.
I read the contributing guide.
The OS-specific logic doesn't appear to be tested in integration and
unit tests, so I didn't add tests.
- **Please check if the PR fulfills these requirements**
* [x] Cheatsheets are up-to-date (run `go generate ./...`)
* [x] Code has been formatted (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting))
* [ ] Tests have been added/updated (see
[here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md)
for the integration test guide)
* [ ] Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [ ] If a new UserConfig entry was added, make sure it can be
hot-reloaded (see
[here](https://github.com/jesseduffield/lazygit/blob/master/docs/dev/Codebase_Guide.md#using-userconfig))
* [ ] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
Opening links containing ampersands inside lazygit (a pull-request
creation page in BitBucket Server, for instance) returns the following
Powershell error:
> The ampersand (&) character is not allowed. The & operator is reserved
> for future use; wrap an ampersand in double quotation marks ("&") to
> pass it as part of a string.
We fix it by enclosing the URL in single quotes.
The OS command to open file in explorer in WSL doesn't currently work as
expected; it always opens the file explorer at the default opening
location. This is because the {{filename}} variable returns the path in
WSL format, and not in the format expected by Windows.
We use wslpath, a utility shipped with WSL, to make the path conversion.
It is needed by both call sites of this function. This has the added benefit
that the argument doesn't unnecessarily show up in the status view when diffing
mode is on.
In 67b8ef449c we changed the "edit" command to insert a "break" after the
selected commit, rather than setting the selected todo to "edit". The reason for
doing this was that it now works for merge commits too.
Back then, I claimed "In most cases the behavior is exactly the same as before."
Unfortunately that's not true, there are two reasons why the previous behavior
was better (both are demonstrated by tests earlier in this branch):
- when editing the last commit of a branch in the middle of a stack of branches,
we are now missing the update-ref todo after it, which means that amending the
commit breaks the stack
- it breaks auto-amending (see the added test earlier in this branch for an
explanation)
For these reasons, we are going back to the previous approach of setting the
selected commit to "edit" whenever possible, i.e. unless it's a merge commit.
The only scenario where this could still be a problem is when you have a stack
of branches, and the last commit of one of the branches in the stack is a merge
commit, and you try to edit that. In my experience with stacked branches this is
very unlikely, in almost all cases my stacked branches are linear.
We will need this because under some conditions we are going to use this
function to edit a range of commits, and we can't set merge commits to "edit".
This corresponds to the code in startInteractiveRebaseWithEdit which has similar
logic.
It is a bit unfortunate that we will have these two different ways of setting
todos to edit: startInteractiveRebaseWithEdit does it after stopping in the
rebase, in the Then function of its refresh, but InteractiveRebase does it in
the daemon with a ChangeTodoActionsInstruction. It still makes sense though,
given how InteractiveRebase works.
This not only affects "edit", but also "drop", "fixup", and "squash".
Previously, when trying to use these for a range selection that includes a merge
commit, they would fail with the cryptic error message "Some todos not found in
git-rebase-todo"; now they simply exclude the merge commit. I'm not sure if one
is better or worse than the other, and we should probably simply disable the
commands when a merge commit is selected, but that's out of scope in this PR.
This is very similar to edit_range_select_outside_rebase.go, except that it
selects commits right after, and including, a merge commit.
This test already works correctly. The reason we add it is that we are going to
have two different implementations of the `e` command depending on whether the
last selected commit is a merge commit, and we want to make sure they both work
with a range selection.
Auto-amending is a little-known feature of git that is very convenient once you
know it: whenever you stop at a commit marked with `edit` in an interactive
rebase, you can make changes and stage them, and when you continue the rebase
they automatically get amended to the commit you had stopped at. This is so
convenient because making changes to a commit is one of the main reasons why you
edit a commit.
Unfortunately this currently doesn't work in lazygit because we don't actually
use `edit` to stop at the first commit (instead, we add a `break` todo after it,
which doesn't have the auto-amend functionality).
We'll improve this later in this branch.
- **PR Description**
This allows range-selecting multiple branches and deleting them all at
once. We allow deleting remote branches (or local and remote branches)
as long as *all* selected branches have one.
We show the warning about force-deleting as soon as at least one of the
selected branches is not fully merged.
We allow deleting remote branches (or local and remote branches) only if *all*
selected branches have one.
We show the a warning about force-deleting as soon as at least one of the
selected branches is not fully merged.
The added test only tests a few of the most interesting cases; I didn't try to
cover the whole space of possible combinations, that would have been too much.
Since we want to select multiselections, this will make it easier to pass a
slice of remote branches. It does require that for the case of the local
branches panel we need to synthesize a RemoteBranch object from the selected
local branch, but that's not hard.
- **PR Description**
Mouse wheel scrolling of the custom patch view worked *unless* a file
(as opposed to a directory) is selected in the commit files view.
Mouse wheel scrolling of the custom patch view worked *unless* a file (as
opposed to a directory) is selected in the commit files view. The reason was an
obvious typo in the AttachControllers call.
This code had a lot of logic that (fortunately) didn't work because it was
buggy:
- it was supposed to wait for the auto-fetch delay before fetching for the first
time in case we start with a repo that we had open in a previous session (i.e.
that appears in the recent repos list). This code actually ran always, not
just for known repos, because the IsNewRepo flag is only set later, after this
function runs. Fortunately, the code didn't work, because time.After starts a
timer but doesn't wait for it (to do that, it would have to be
`<-time.After`).
- if the first fetch fails with error 128, it was supposed to show an error
message and not start the background fetch loop. Fortunately, this didn't work
because 1) it was guarded by isNew which is always false here, and 2) because
git's error message in this case is actually "exit code: 128", not "exit
status 128" (maybe this has changed in git at some point).
I find both of these undesirable. Whenever I open a repo I want an auto-fetch to
be triggered immediately to get my branch information up to date as quickly as
possible. And if the initial fetch fails (e.g. because one of my remotes is
offline or doesn't exist any more), then that's no reason not to start the
auto-fetch loop anyway.
So let's simplify the code to do what it did before, but with much fewer lines
of code.
Original commit message of the gocui change:
This fixes View.Size, Width and Height to be the correct (outer) size of a view
including its frame, and InnerSize/InnerWidth/InnerHeight to be the usable
client area exluding the frame. Previously, Size was actually the InnerSize (and
a lot of client code used it as such, so these need to be changed to InnerSize).
InnerSize, on the other hand, was *one* less than Size (not two, as you would
have expected), and in many cases this was made up for at call sites by adding 1
(e.g. in calcRealScrollbarStartEnd, parseInput, and many other places in the
lazygit code).
There are still some weird things left that I didn't address here:
- a view's lower-right coordinates (x1/y1) are one less than you would expect.
For example, a view with a 2x2 client area like this:
╭──╮
│ab│
│cd│
╰──╯
in the top-left corner of the screen (x0 and y0 both zero) has x1/xy at 3, not
4 as would be more natural.
- a view without a frame has its coordinates extended by 1 on all sides; to
illustrate, the same 2x2 view as before but without a frame, sitting in the
top-left corder of the screen, has coordinates x0=-1, y0=-1, x1=2, y1=2. This
is highly confusing and unexpected.
I left these as they are because they would be even more of a breaking change,
and also because they don't have quite as much of an impact on general app code.
- **PR Description**
Some editors add one automatically when saving the file, which causes
confusion and ugly diffs containing `\ No newline at end of file`.
When creating a PR against a selected branch (via O = "create pull
request
options"), the user will first be asked to select a remote (if there is
more
than one). After that, the suggestion area is populated with all remote
branches
at that origin - instead of all local ones. After all, creating a PR
against a
branch that doesn't exist on the remote won't work.
Please note that for the "PR is not filed against 'origin' remote" use
case
(e.g. when contributing via a fork that is 'origin' to a GitHub project
that is
'upstream'), the opened URL will not be correct. This is not a
regression and
will be fixed in an upcoming PR.
Fixes#1826.
When creating a PR against a selected branch (via O = "create pull request
options"), the user will first be asked to select a remote (if there is more
than one). After that, the suggestion area is populated with all remote branches
at that origin - instead of all local ones. After all, creating a PR against a
branch that doesn't exist on the remote won't work.
Please note that for the "PR is not filed against 'origin' remote" use case
(e.g. when contributing via a fork that is 'origin' to a GitHub project that is
'upstream'), the opened URL will not be correct. This is not a regression and
will be fixed in an upcoming PR.
Fixes#1826.
- **PR Description**
Found that the method to pull the latest tarball for the project was
incorrect. This pull request fixes the instructions in the Ubuntu
section of the Readme.
Simple fix to README.md
# **PR Description**
## Problem this PR attempts to solve
I really appreciate the feature added in #3794 that allows switching
tabs using panel jump keys when the side panel is already active and see
how it is convenient for many users. However, after using lazygit for
quite some time, I've developed muscle memory where I rely on pressing a
number key to instantly switch to a panel and perform an action,
regardless of which panel is currently active. I have found myself
several times in the past few days clicking '2' and going to hit 'a' +
'c' to commit all and find I was already had window 2 active and my tab
was instead switched to 'Worktrees' and the keybindings no longer apply
to stage or commit.
## Solution
- Add a config `SwitchTabsWithPanelJumpKeys` as a gui boolean that is
true by default, keeping the current new behavior added by #3794
- When `SwitchTabsWithPanelJumpKeys` is set to false in the user's
config, the old behavior is returned which does not switch tabs using
the side panel jump keys.
- This is behavior is verified with an integration test with
``SwitchTabsWithPanelJumpKeys` set to false that shows the expected
behavior that jumping to window 2 while window 2 is already active does
not switch tabs within window 2
To disable switching tabs with panel jump keys, add the following to
your config.yml:
```yaml
gui:
# 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
```
### P.S.
This is my first contribution to lazygit and while I absolutely strived
to read all documentation and follow all standards, I accept that this
PR may not be perfect and am very open to feedback and suggestions to
improve both this code and any future contributions. I absolutely love
lazygit, I use it everyday and swear by it as the most powerful and
efficient tool for managing git, I love and appreciate all the work all
the maintainers do to constantly improve it. So thank you to all who are
reading this and I look forward to contributing more to make lazygit
even more of the best git tool available!
* [x] Cheatsheets are up-to-date (run `go generate ./...`)
* [x] Code has been formatted (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting))
* [x] Tests have been added/updated (see
[here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md)
for the integration test guide)
* [ ] No text rendered to user -> Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [x] If a new UserConfig entry was added, make sure it can be
hot-reloaded (see
[here](https://github.com/jesseduffield/lazygit/blob/master/docs/dev/Codebase_Guide.md#using-userconfig))
* [x] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
<!--
Be sure to name your PR with an imperative e.g. 'Add worktrees view'
see https://github.com/jesseduffield/lazygit/releases/tag/v0.40.0 for
examples
-->
This is both a bug fix and a behavior change:
- The bug fix is that when entering the staging view for a selected file
by clicking in the main view, and the main view was scrolled down, then
it would scroll to the top and show an ugly range selection from the
line that was clicked to the line that is now under the mouse after
scrolling up.
- The behavior change is that when leaving the staging view by pressing
escape, it now retains its scroll position rather than scrolling back up
to the top.
In addition, this fixes a minor flickering issue when leaving the
staging view.
Note that maintaining the scroll position when going into and out of the
staging view is not always perfect for two reasons:
- the focused staging view does not wrap long lines, but the unfocused
one does
- a pager like delta might change the number of lines e.g. of the diff
hunks
For the second problem there's little we can do, but the first one will
be improved once we wrap lines in the focused staging view (see #1384
and #3558), which I'm currently working on.
- **Please check if the PR fulfills these requirements**
* [x] Cheatsheets are up-to-date (run `go generate ./...`)
* [x] Code has been formatted (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#code-formatting))
* [ ] Tests have been added/updated (see
[here](https://github.com/jesseduffield/lazygit/blob/master/pkg/integration/README.md)
for the integration test guide)
* [ ] Text is internationalised (see
[here](https://github.com/jesseduffield/lazygit/blob/master/CONTRIBUTING.md#internationalisation))
* [ ] If a new UserConfig entry was added, make sure it can be
hot-reloaded (see
[here](https://github.com/jesseduffield/lazygit/blob/master/docs/dev/Codebase_Guide.md#using-userconfig))
* [ ] Docs have been updated if necessary
* [x] You've read through your own file changes for silly mistakes etc
As far as I understand, this was needed back when the staging context was still
responsible for rendering its highlight (as opposed to the gocui view, as it is
today). It was necessary to call it with isFocused=false so that it removed the
highlight. The isFocused bool is no longer used today (and we'll remove it in
the next commit), so there's no need to render the view here any more.
This fixes flickering when leaving the staging view by pressing escape. The
reason is that in this case the patch state was already set to nil by the time
we get here, so we would render an empty view for a brief moment.
On top of that, it fixes unwanted scrolling to the top when leaving the staging
view. The reason for this is that we have code in layout that scrolls views up
if needed, e.g. because the window got taller or the view content got shorter
(added in #3839). This kicked in because we emptied the view, and scrolled it
all the way to the top, which we don't want.
This way it won't scroll to the top; we want this when entering the staging
panel or the patch building panel by clicking into the view, and also when
returning from these views by pressing escape. Note that there's a bug in this
latter case: the focused panel still scrolls to the top when hitting escape, we
will fix this in the next commit.
Change it in the same way for NewRenderStringWithScrollTask, just for
consistency, although it's not really necessary there. We use this function only
for focusing the merge conflict view, and in that case we already have an empty
task key before and after, so it doesn't change anything there.
When clicking in a single-file diff view to enter staging (or custom patch
editing, when coming from the commit files panel), and then pressing shift-down
or shift-up to select a range, it would move the selected line rather than
creating a range. Only on the next press would it start to select a range from
there.
This is very similar to the fix we made for pressing escape in 0e4d266a52.
When clicking in the main view to enter staging, and then pressing shift-down to
select a range, it moves the selection rather than selecting a two-line range.
We'll fix this in the next commit.
So far we only had tests that called Click() only once. If you have a test that
calls Click twice (we'll add one in the next commit), you'll notice that the
second click is interpreted as a drag because the mouse button wasn't released
in between. Fix this by sending a "mouse-up" event after the click.
After pasting commits once, we hide the cherry-picking status (as if it had been
reset), and no longer paint the copied commits with blue hashes; however, we
still allow pasting them again. This can be useful e.g. to backport a bugfix to
multiple major version release branches.
The string literal "\uf0868" does *not* create a single rune with the code point
f0868, as was intended; instead, it creates two runes, one with the code point
f086, followed by the character '8'.
Currently we try to delete a branch normally, and if git returns an error and
its output contains the text "branch -D", then we prompt the user to force
delete, and try again using -D. Besides just being ugly, this has the
disadvantage that git's logic to decide whether a branch is merged is not very
good; it only considers a branch merged if it is either reachable from the
current head, or from its own upstream. In many cases I want to delete a branch
that has been merged to master, but I don't have master checked out, so the
current branch is really irrelevant, and it should rather (or in addition) check
whether the branch is reachable from one of the main branches. The problem is
that git doesn't know what those are.
But lazygit does, so make the check on our side, prompt the user if necessary,
and always use -D. This is both cleaner, and works better.
See this mailing list discussion for more:
https://lore.kernel.org/git/bf6308ce-3914-4b85-a04b-4a9716bac538@haller-berlin.de/
It's maybe not very common, but it's totally possible for a remote branch to
have a different name than the local branch. This test shows that we don't
support this properly when deleting the remote branch.
[This video](https://www.youtube.com/watch?v=kNavnhzZHtk) walks through the process of adding a small feature to lazygit. If you have no idea where to start, watching that video is a good first step.
## Design principles
See [here](./VISION.md) for a set of design principles that we want to consider when building a feature or making a change.
Lazygit's vision is to be the most enjoyable UI for git.
## Design Principles
There are seven (sometimes contradictory) design principles we follow:
- Dicoverability
- Simplicity
- Safety
- Power
- Speed
- Conformity with git
- Think of the codebase
### Discoverability
TUI's are notoriously hard to learn, thanks to limited screen real-estate to provide contextual help and a general lack of effort on the part of developers to make things obvious. We want Lazygit to buck the trend and be easy for a new user to grok.
Examples:
- Clearly document all the features/configuration options
- e.g. gifs in the README
- Document how to solve various git problems with Lazygit
- This is something we don't have yet but should: a section in the docs explaining how Lazygit can help you in various scenarios
- Use tooltips to explain what actions will do
- Make it easy for users to ask questions and get answers from the community
- Make it easy to find entities and actions from within Lazygit
- Use visual elements to make things obvious
- e.g. '<-- YOU ARE HERE' label when rebasing
- Don't require the user to memorise keybindings
- e.g. when the user is mid-rebase, we prominently show that the keybinding for viewing rebase options is 'm'
- When the user performs an action in Lazygit, make the impact obvious
- If the affected entity isn't visible, show a toast notification
- If a keybinding is disabled, give a reason why
### Simplicity
The git CLI is very complex but most git use cases are simple. Lazygit needs to ensure that simple use cases are easy to satisfy.
- Make the most common use cases dead-simple (staging files, committing, pulling/pushing)
- Don't overwhelm the user with options
- Use sensible defaults
- We already have too many configuration options: think hard before adding any new ones
### Safety
It's easy to screw things up in git so Lazygit should try to protect the user from screwing things up.
- Prompt for a confirmation before doing anything that's hard to reverse
- Make it easy to correct mistakes
- e.g. undo action
- the escape key should get you out of most transient situations (rebasing, diffing, etc)
## Power
Users shouldn't have to drop down the CLI _too_ often. Lazygit should be able to handle some complex use cases.
- Make complex (but common) CLI flows simple
- e.g. interactive rebasing
- Use the custom commands system to handle the really rare complex edge-cases
### Speed
Pro users should be able to move at lightning speed with Lazygit.
- Always think about the number of keypresses involved in a given UX flow
- Make lazygit performant and responsive
- Think about the individual commands being run and how fast they are
- Startup should be FAST. If you want to run something at startup that is slow, make it non-blocking.
- Support muscle-memory
- Prefer disabling menu items instead of hiding them so that muscle memory can be used to select the desired menu item
- Try to make keybinding intuitions to transfer across contexts (e.g. 'd' for destroy)
- When changing keybindings in a new release, always consider what will happen if a user does not read the release notes and relies on muscle memory.
### Conformity with git
Satisfying the use-cases of git users is more important than perfectly conforming to git's API, but even obscure parts of git's API were motivated by real use-cases.
- Users should only have to drop down to the git CLI in rare circumstances
- Honour the git config
- Don't override anything set in the git config without the user's permission
- Work with git, not against it.
- Too much magic will get us into trouble
- Avoid storing Lazygit-specific session state that could instead be stored in git
- Ensure that Lazygit can represent the state of any repo
- Sometimes git's default behaviour is just silly and we'll make the call to override but it should be a well-considered decision.
### Think of the codebase
Will somebody PLEASE think of the codebase!
Some features are not worth the added complexity in the codebase. The more this codebase grows, the harder it will be to make the changes that everybody wants.
## Resolving conflicts
Many of the above objectives are directly antithetical to one another. If you add an extra confirmation prompt for the sake of _safety_, you're sacrificing _speed_. If you support toggling various git flags in the name of _power_, you're sacrificing _simplicity_. There are a few things to say here.
When there are conflicts, we need to make a judgement call. In general we should err on the side of safety and simplicity as the default, with the ability for users to make things faster / more powerful either through configuration or separate keybindings.
This does not mean for example that force pushes should be impossible without being manually enabled: force pushes are table stakes for anybody who rebases. But it does mean that a confirmation popup should appear when force pushing.
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:
@@ -656,9 +674,26 @@ os:
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:
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`:
A custom command for reading from the clipboard can be set using
@@ -905,6 +940,14 @@ git:
replace:'[$1] '
```
> [!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.
@@ -50,7 +50,7 @@ Custom command keybindings will appear alongside inbuilt keybindings when you vi
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) | yes |
| 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 |
| subprocess | Whether you want the command to run in a subprocess (e.g. if the command requires user input) | no |
This topic deserves its own doc because there 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:
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:
flaggy.String(&customConfigFile,"ucf","use-config-file","Comma separated list to custom config file(s)")
screenMode:=""
flaggy.String(&screenMode,"sm","screen-mode","The initial screen-mode, which determines the size of the focused panel. Valid options: 'normal' (default), 'half', 'full'")
// Uniquefy windows by dimensions (so perfectly overlapping windows are de-duped). This prevents getting 'fileshes' as a label where the files and branches windows overlap.
// Uniquify windows by dimensions (so perfectly overlapping windows are de-duped). This prevents getting 'fileshes' as a label where the files and branches windows overlap.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Jesse Duffield
Stefan Haller
Nikita Karamov
Brandon
github-actions[bot]
ZeroMask
Sebastian Mangelsen
Nathan Baulch
RiceChuan
John Mutuma
John Mutuma
A. Jensen
Alex Lewis
Elias Assaf
hasecilu
Wayne Bowie
Sebastian Flügge
wadsaek
Sergey Kochetkov
Samuel Dominguez
johannaschwarz
Baptiste Ottino
phanirithvij
Moritz Haase
LU Jialin
Eng Zer Jun
Yaroslav Veremenko
Stephen Martin
Harris Greenstein
Shaobo Song