1
0
mirror of https://github.com/jesseduffield/lazygit.git synced 2025-06-10 23:57:43 +02:00

6499 Commits

Author SHA1 Message Date
Stefan Haller
0d5c748fe8 Show the same menu when pressing space on a remote branch
The old behavior of showing a prompt to choose a name for the new local branch
is still available via the 'n' keybinding.
2024-03-17 07:53:38 +01:00
Stefan Haller
e42cbf95ae When checking out a remote branch by name, ask the user how
The choices are to create a new local branch that tracks the remote, or a
detached head.
2024-03-17 07:53:38 +01:00
Stefan Haller
0360b82aab
Don't ask to force-push if the remote rejected updates (#3387)
Lazygit has two ways to decide whether it needs to ask the user to
force-push:
1. if it knows ahead of time that the push will fail because the branch
has diverged, by looking at the incoming/outgoing information that it
shows as ↑3↓7.
2. by examining the error that comes back when the push has failed.

The second situation should happen only rarely, because lazygit fetches
every minute by default, so the ↑3↓7 information is usually up to date.
It might not be if the user turned off auto-fetch (or increased the
auto-fetch interval). However, in this case it's almost always harmful
to prompt the user to force-push, because we know that the reason for
diverging is that something was pushed to the remote, and we would wipe
it out by force-pushing. In such a situation, the more likely user
action is to pull the remote changes and then push normally again.

So just remove the second prompt, and replace it by a better error
message when we detect that updates were rejected remotely.

A little bit of history archeology reveals that the second prompt was
added at a time where we didn't have the first one yet, so at that time
it made sense to have it; but when the first prompt was added, we should
have removed the second.
2024-03-17 07:42:34 +01:00
Stefan Haller
81b497d186 Don't ask to force-push if the remote rejected updates
Lazygit has two ways to decide whether it needs to ask the user to force-push:
1. if it knows ahead of time that the push will fail because the branch has
diverged, by looking at the incoming/outgoing information that it shows as ↑3↓7.
2. by examining the error that comes back when the push has failed.

The second situation should happen only rarely, because lazygit fetches every
minute by default, so the ↑3↓7 information is usually up to date. It might not
be if the user turned off auto-fetch (or increased the auto-fetch interval).
However, in this case it's almost always harmful to prompt the user to
force-push, because we know that the reason for diverging is that something was
pushed to the remote, and we would wipe it out by force-pushing. In such a
situation, the more likely user action is to pull the remote changes and then
push normally again.

So just remove the second prompt, and replace it by a better error message when
we detect that updates were rejected remotely.

A little bit of history archeology reveals that the second prompt was added at a
time where we didn't have the first one yet, so at that time it made sense to
have it; but when the first prompt was added, we should have removed the second.
2024-03-17 07:38:58 +01:00
Stefan Haller
e9d050c5d5
Allow moving and deleting update-ref todos (#3391)
- **PR Description**

Previously it wasn't possible to move an update-ref entry up or down
using ctrl-j and ctrl-k, or to delete an update-ref entry. For moving, a
work-around was to move the surrounding commits instead, but it's still
nice to be able to do it directly. Deleting is very much necessary
though, since there are situations where git adds the update-ref entries
but they are not wanted; one example is if you want to make a copy of a
branch and rebase to a different place, without the original branch
following it. (There's a long discussion about this
[here](https://public-inbox.org/git/adb7f680-5bfa-6fa5-6d8a-61323fee7f53@haller-berlin.de/).)

Update-ref todos can't be set to "drop" like other todos, because they
have no sha associated with them, so we need to delete them immediately.
We show a confirmation before doing that, because you'd have to abort
the rebase if you do it accidentally.

We allow range selecting normal todos and update-ref todos at the same
time; in that case, we delete all the update-ref todos and set all the
other ones to "drop". Not that this is an absolutely necessary feature,
but it wasn't hard to do.
2024-03-17 07:38:25 +01:00
Stefan Haller
5c56bc7015 Set mode to none when calling SetSelectionRangeAndMode with empty non-sticky range
So far, the only situation where we called SetSelectionRangeAndMode was one
where the range could only get larger (in startInteractiveRebaseWithEdit, in
which case update-ref todos can be inserted by the rebase). However, in the last
commit we introduced a new call site where the range can get smaller, including
being reduced to a single item. Since this is indistinguishable from a single
selection, set the mode to none in this case; without this, hitting escape would
seemingly do nothing because it collapses the empty range selection.
2024-03-16 22:01:13 +01:00
Stefan Haller
0608fc6471 Allow deleting update-ref todos 2024-03-16 22:01:13 +01:00
Stefan Haller
64a1a455d6 Extract a findTodo helper function
We will reuse it in the next commit.
2024-03-16 22:01:03 +01:00
Stefan Haller
bd975a8dcb Allow moving update-ref todos up/down 2024-03-16 22:01:03 +01:00
Stefan Haller
e5fa9e1c4a Store full ref in Name field of update-ref commits
Strip the prefix at presentation time instead. This makes it easier to find
update-ref todos in order to move them up/down, or delete them.
2024-03-16 15:48:34 +01:00
Stefan Haller
e8d84a1f2c Refactor: pass Todo to moveTodoUp/Down instead of Sha and Action
We need this because we want to enable moving update-ref todos, which don't have
a sha.
2024-03-16 15:21:17 +01:00
Stefan Haller
fd18db6ba2
Show "breaking changes" message at startup (#3377)
- **PR Description**

Remember which version of lazygit the user was last running, and show a
list of breaking changes since that version (if any) if the user
upgraded to a newer version.

It's a little unobvious how to test this manually, because we don't show
the popup for developer builds. You'll have to build with something like
`go build -ldflags="-X 'main.version=0.41.0'"` in order to test it.

This is an extremely stripped down version of #3261.
2024-03-12 13:30:19 +01:00
Stefan Haller
36fa25fa6d Handle mouse-wheel scrolling in confirmation panel
This can easily happen for the breaking changes panel when there are many.
2024-03-12 13:27:14 +01:00
Stefan Haller
2f4437591e Show popup message with breaking changes on startup 2024-03-12 13:27:14 +01:00
Stefan Haller
d12ceeb1ec
Add Co-Author support to new commits (#3097)
- Adds Co-Author support to commit menu (`<C-o>` by default) 
  - `e` Opens up the commit message in your editor
  - `c` Lets you add a co author to your commit
- Cleans up and amend commit attribute menu related code
2024-03-12 08:40:47 +01:00
Stefan Haller
1ec87364fe Add integration test 2024-03-11 09:19:11 +01:00
Abhishek Keshri
7c687938a5 Add commit menu entry "Add co-author" 2024-03-11 09:18:55 +01:00
Abhishek Keshri
744519de60 Add a commit menu to the commit message panel
And move the "switch to editor" command into this menu. So far this is the only
entry, but we'll add another one in the next commit.
2024-03-11 09:18:40 +01:00
Stefan Haller
b8f4cd0ef6 Extract functions AddCoAuthorToMessage and AddCoAuthorToDescription
In this commit we only need the former; the latter will be reused later in this
branch.
2024-03-11 09:18:40 +01:00
Stefan Haller
287195b5b2 Make test assertion more specific
It's safe to rely on git padding the log messages with exactly four spaces (I
think). This makes the diff of the following commit slightly clearer.
2024-03-11 09:18:40 +01:00
Abhishek Keshri
e1b341e174 Make keybindings for the "Amend attribute" menu configurable 2024-03-11 09:18:40 +01:00
Abhishek Keshri
b1523c3f07 Internationalize the tooltips of the "Amend commit attributes" menu 2024-03-11 09:18:40 +01:00
Abhishek Keshri
c3c5753a35 Add forgotten keybindings to Config.md 2024-03-11 09:18:40 +01:00
Jesse Duffield
272e41929c Update sponsors in readme 2024-03-09 20:48:33 +11:00
Stefan Haller
ac4767bb2a
Auto-wrap commit message while typing (#3173)
- **PR Description**

Add new config settings `git.commit.autoWrapCommitMessage` (default
true) and `git.commit.autoWrapWidth` (default 72), which allow automatic
as-you-type wrapping of the commit message body to the specified width.

There are occasional situations where this wrapping is in the way, for
example when you need to have longer lines in the message for some
reason (perhaps because you have a very wide ASCII art picture or
table), and you'll have to resort to switching to the editor in that
case. However, in my experience these cases are quite rare.
2024-03-09 10:06:29 +01:00
Stefan Haller
d1f8c45099 Add integration test 2024-03-09 10:00:44 +01:00
Stefan Haller
41a68f7c4a Remove hard line breaks when rewording commits
... and when recalling a commit message from an old commit by pressing up-arrow.

This is necessary because committing turns our soft line breaks into real ones,
but when rewording we want to turn them back into soft ones again, so that it's
possible to insert words at the beginning of a paragraph and have everything
rewrap nicely.

This is only a best effort; the algorithm only removes those hard line breaks
that can be removed without changing the way the message looks. This works well
when the previous commit message was wrapped at the same width, which for most
users should be the most common case; but if it wasn't, the result is not great.
Specifically, if the old wrap width was smaller, some hard line breaks just
won't be removed; if it was wider though, you'll get an unpleasant comb effect
with alternating long and short lines. In such a case it's best to switch to the
editor and use whatever wrapping features you have there (e.g. alt-Q).
2024-03-09 10:00:44 +01:00
Stefan Haller
944d82028f Replace DOS linefeeds with Unix line feeds when loading a commit message
I have seen some commit messages that contain CRLF instead of just LF; I'm not
sure if these were created by a broken git client, but they exist, so we need to
deal with them. Editing them when rewording a commit sort of works, but is a
little strange; the \r characters are invisble, so you need an extra arrow key
press to skip over them.

In the next commit we are going to add more logic related to line breaks, and it
is getting confused by the \r, so it is becoming more important to fix this. The
easiest fix is to normalize the line endings right after loading.
2024-03-09 10:00:44 +01:00
Stefan Haller
379a6f1922 Save and restore the unwrapped description
When preserving the commit message (when cancelling a commit), and later
restoring it, use the unwrapped description.
2024-03-09 10:00:44 +01:00
Stefan Haller
cede021400 Add config for soft-wrapping the commit message body 2024-03-09 10:00:44 +01:00
Stefan Haller
99ad6005e8 Bump gocui 2024-03-09 10:00:07 +01:00
Stefan Haller
dc9ee186f4
Adjust selection after squashing fixups (#3338)
- **PR Description**

Keep the same commit selected after squashing fixup commits, and after
creating fixup commits.

Edge case: it is now possible to have a range of commits selected when
squashing fixups (by using the "in current branch" version of the
command), and in that case we don't bother preserving the range. It
would be possible, but would require more code, and I don't think it's
worth it, so I'm simply collapsing the range in that case.
2024-03-09 07:58:14 +01:00
Stefan Haller
bb26979420 Keep the same line selected after squashing fixup commits
This uses a bit of a heuristic that is hopefully correct most of the time.
2024-03-09 07:55:22 +01:00
Stefan Haller
c6d20c876e Extract common code to a helper method
This should arguably have been done in b133318b40 already; it's becoming more
important now because we're going to extend the common code with more logic in
the next commit.
2024-03-09 07:55:22 +01:00
Stefan Haller
3e3b902228 Move selection down by one after creating a fixup commit 2024-03-09 07:55:22 +01:00
Stefan Haller
dfb45ba893 Extend squash_fixups_in_current_branch test to check the selection
This shows a problem with the wrong commit being selected after squashing.
2024-03-09 07:55:22 +01:00
Stefan Haller
314efe2539 Add test for creating a fixup commit and squashing fixups
We have such a test already (squash_fixups_above_first_commit.go), but it can't
be used for what we want to check here, because it uses the first commit, and we
can't move down from there. So create a new one that basically does the same
thing, but for a commit in the middle. The focus of this new test is to check
how the selection behaves; as you can see, there is a problem both when creating
a fixup and when squashing fixups. We'll address these separately in the next
commits.
2024-03-09 07:55:22 +01:00
Stefan Haller
bbc680266b
Support setting a range of commits to "edit" outside of a rebase (#3370)
- **PR Description**

It is now possible to select a range of commits (while not in a rebase),
and hit "e" to edit them all. This starts a rebase on the bottom-most
commit of the range, and sets all the selected commits to "edit"
(skipping merge commits, because they can't be edited).
2024-03-09 07:46:34 +01:00
Stefan Haller
40232440b7 Support setting a range of commits to "edit" outside of a rebase
It starts a rebase on the bottom-most commit of the range, and sets all the
selected commits to "edit" (skipping merge commits, because they can't be
edited).
2024-03-09 07:43:48 +01:00
Stefan Haller
44f553b609
Show all submodules recursively (#3341)
- **PR Description**

Extend the submodules tab to show not only the top-level submodules, but
also their nested submodules, recursively.

Fixes #3306.
2024-03-07 20:20:42 +01:00
Stefan Haller
3b723282cb Show all submodules recursively 2024-03-07 20:16:28 +01:00
Stefan Haller
db4f12929e Pass entire submodule to UpdateUrl instead of name and path separately
This will make the next commit slightly simpler.
2024-03-07 20:16:28 +01:00
Stefan Haller
ea87912a74 Fix deleting submodule where name and path are different 2024-03-07 20:16:28 +01:00
Stefan Haller
ddcd916301 Add test to check that the git dir for a deleted submodule was removed
The test shows that it actually doesn't work when the submodule name is
different from its path. We'll fix this in the next commit.
2024-03-07 20:16:28 +01:00
Stefan Haller
85a6a42bff Extend submodule tests to use a submodule where name and path are different
In most real-world scenarios, name and path are usually the same. They don't
have to be though, and it's important to make sure we use the right one when
passing arguments to git commands, so change the tests to have different name
and path.
2024-03-07 20:16:28 +01:00
Stefan Haller
ad017459d2
Don't strike out reserved keys in menus (#3365)
It seems to cause more confusion than it helps.

Fixes #2819.
2024-03-07 07:30:08 +01:00
Stefan Haller
cfaf4b29d0 Don't strike out reserved keys in menus
It seems to cause more confusion than it helps.
2024-03-06 18:41:27 +01:00
Stefan Haller
8d9e5d1258
Bump gocui (#3356)
This resolves the regression from the last gocui bump that strikethrough
no longer worked.

Fixes #3355.
2024-03-03 18:46:50 +01:00
Stefan Haller
212ec7e8e5 Bump gocui
This resolves the regression from the last gocui bump that strikethrough no
longer worked.
2024-03-03 18:41:03 +01:00
Stefan Haller
0f14065245
Remove support for old style non-interactive rebase (#3348)
When doing a non-interactive rebase using a version of git earlier than
2.26, or by explicitly calling `git -c rebase.backend=apply rebase`,
lazygit can display the pending todos by parsing the numbered patch
files in `.git/rebase-apply/`. Unfortunately, support for this has been
broken for more than three years because of the change in 682db77401e
(the string literal "normal" should have been changed to
REBASE_MODE_NORMAL instead of REBASE_MODE_MERGING).

It's not an important bug since you can only get into this situation by
doing a rebase outside of lazygit, and then only with a pretty old git
version or by using very uncommon git options. So instead of fixing the
bug, just remove the code.
2024-03-02 10:28:37 +01:00