Users can copy commits from one repo to another with "git format-patch"
and "git am", for example with custom commands. If "git am" stopped
with a conflict, lazygit showed this as a rebase, because git am uses
the rebase-apply directory too. The rebase options in the m menu didn't
work either; git refuses to run "git rebase --continue" during an am.
Recognize an am by the rebase-apply/applying file, and call this state
"applying patches". The m menu then offers "git am --continue",
"--abort" and "--skip".
If "git am --continue" finds nothing to commit, it says "No changes -
did you forget to use 'git add'?". Unlike for a rebase, don't skip the
patch in that case. Without --3way, git am leaves the files alone if a
patch doesn't apply, and skipping would lose the patch.
If a lock error stops "git am --continue" or "--skip" after it has moved
on to the next patch, don't run it again; this could skip that patch.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The texts for aborting or continuing a merge, rebase, cherry-pick or
revert insert the git command name into the sentence, as in "Abort the
rebase". We are going to support "git am" next, and "Abort the am"
makes no sense.
Give each operation a translated phrase like "the rebase" instead, and
use it as a placeholder in these texts. Rename the texts too. The
existing translations still use %s, and this way lazygit ignores them
until they are updated.
This changes the wording of the abort confirmation slightly, from
"Abort rebase" to "Abort the rebase", and from "abort the current
rebase" to "abort the rebase".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Our git command runner has logic to retry a failed git command if it can
determine that the failure was caused by an index.lock held by a
background process. This is great, but it's the wrong thing to do for an
interactive rebase that fails while applying one of its pick todos; in
that case, git stops in the middle of the rebase, and retrying it
results in a confusing error ("a rebase is already in progress").
This is just one of many examples of what can go wrong when retrying
rebase, cherry-pick, or revert commands that fail with an index.lock
error; this PR tries to handle as many situations as reasonable
automatically (e.g. by issuing `git rebase --continue` when a pick
failed and lazygit can confirm that the pick was rescheduled by git).
See the individual commits for details.
If git can't take the index lock to commit the changes of a pick during
a rebase, it exits without writing rebase-merge/stopped-sha. Lazygit
then showed the rebase as a cherry-pick, because it only recognized
CHERRY_PICK_HEAD as part of a rebase if stopped-sha matched it.
Also accept CHERRY_PICK_HEAD as part of the rebase if it matches the
last todo in rebase-merge/done, the pick that git was executing.
With this, continuing runs "git rebase --continue". In this state it
refuses to commit the staged changes of the pick, because git didn't
write the message file that it writes when a pick conflicts. So commit
them first with "git cherry-pick --continue". This uses the author and
message of the pick, like the rebase would have.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If git can't take the index lock to commit the changes of a pick during
a rebase, it exits without recording that the rebase stopped. It leaves
CHERRY_PICK_HEAD behind, but no rebase-merge/stopped-sha. Lazygit only
recognizes CHERRY_PICK_HEAD as part of a rebase if stopped-sha matches
it, so it shows the rebase as a cherry-pick.
Its "Cherry-pick options" then run cherry-pick commands during the
rebase. Continuing happens to work, but takes two steps. Skipping or
aborting discards the changes of the pick, and continuing the rebase
afterwards loses that commit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If a lock stops "git rebase --skip" after git has applied the changes
of the next commit but before it has committed them, running it again
discards those staged changes, and the commit is lost. Something
similar happens with "git cherry-pick --continue" and "--skip" (and
the same for revert). If the lock stops them at the next commit, git
doesn't reschedule that commit, and running them again skips it.
For a rebase, handle continue and skip like the commands that start a
rebase. Run the command again if the lock stopped it before it changed
the state of the rebase, continue if git rescheduled the todo that
failed, and give up otherwise. For a cherry-pick or revert, run the
command again if it didn't change the todos in .git/sequencer, and
give up otherwise.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If a lock stops "git rebase --skip" after git has applied the changes
of the next commit but before it has committed them, git doesn't
reschedule that commit. The changes stay staged. The git command runner
then runs "git rebase --skip" again, and this discards the staged
changes, so the commit is silently lost.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If a lock stops a cherry-pick or revert of several commits partway
through, the git command runner ran the same command again. This failed
with "cherry-pick is already in progress", and the user was left with
an operation that stopped halfway. Continuing it would skip the commit
that failed, because git doesn't reschedule it the way a rebase does.
Abort the operation instead, and then run the command again. Also
abort when the runner gives up, so that the user doesn't end up with
the stopped operation.
Only do this for several commits. For a single commit, git doesn't use
.git/sequencer, and a cherry-pick of one commit may even run while a
cherry-pick of several commits is in progress. If .git/sequencer exists
after a single cherry-pick failed, it belongs to that other operation,
and we must not abort it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If a lock stops a cherry-pick of several commits partway through, the
git command runner runs the same "git cherry-pick" command again. This
fails with "cherry-pick is already in progress", and the user is left
with a cherry-pick that stopped halfway. Unlike a rebase, git doesn't
reschedule the commit that failed, so continuing the cherry-pick would
skip that commit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If a cherry-pick or revert of several commits stops before git starts
to apply one of them, git doesn't write CHERRY_PICK_HEAD or REVERT_HEAD.
It only leaves the todos behind in .git/sequencer.
Look at the first todo there, like git status does. If it is a "pick"
or "revert", consider a cherry-pick or revert to be in progress.
Once we show such an operation, two more things need care. The same
state occurs if the user resolves a conflict and commits the result
themselves. Git tells the two cases apart by whether HEAD has moved
since it last tried to apply a commit, so do the same. Mark the commit
that git stopped at as conflicted only if CHERRY_PICK_HEAD or
REVERT_HEAD exists, and don't show it as pending if the user has
committed it.
Also, "git cherry-pick --continue" skips the commit that git stopped
at, even if git never applied it. Before continuing in that case, put a
copy of its todo in front of it, so that git skips the copy instead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If a cherry-pick of several commits stops before git starts to apply
one of them, for example because the commit would overwrite an
untracked file, lazygit doesn't show the cherry-pick as in progress.
Git doesn't write CHERRY_PICK_HEAD in that case, and this is the only
thing we look at. The user has no way to continue or abort the
cherry-pick from lazygit, and the next cherry-pick fails with
"cherry-pick is already in progress".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If pull.rebase is set and a lock stops the rebase partway through, the
git command runner ran "git pull" again. This failed with "You are not
currently on a branch", and the rebase was left stopped halfway.
Handle this the same way as for an interactive rebase. Continue the
rebase if git rescheduled the todo that failed, give up if it didn't,
and run the pull again if the lock stopped it before the rebase
started.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This has the same problem as an interactive rebase. If pull.rebase is
set and a lock stops the rebase partway through, the git command runner
runs "git pull" again. This fails with "You are not currently on a
branch" because HEAD is detached during the rebase, and the rebase is
left stopped halfway.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If another git process takes index.lock while a rebase is replaying
commits, git stops the rebase and reschedules the todo that failed. The
git command runner then ran the whole "git rebase --interactive" command
again. This failed because the rebase was already in progress, and the
user was left with a rebase that stopped halfway.
Continue the rebase with "git rebase --continue" instead; this runs the
rescheduled todo again. Only do this if the todo files show that git
rescheduled it. In some cases git doesn't, for example if the lock stops
a pick after it has applied the changes but before it has committed
them. Continuing is not safe in that case, so give up and show the
error.
If the lock stops the command before the rebase starts, git cleans up
after itself, and we run the command again as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If another git process takes index.lock while a rebase is replaying
commits (for example an IDE running "git status" in the background),
git stops the rebase and reschedules the command that failed. Lazygit
then runs the whole "git rebase --interactive" command again. This
fails with "It seems that there is already a rebase-merge directory",
and the user is left with a rebase that stopped halfway.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The next commit needs a "git rebase --continue" command with this setup
that the git command runner runs, rather than one that we run directly.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The git command runner runs a command again if it failed because
another git process held a lock. This is wrong for a command that starts
an operation of several steps, such as a rebase or a cherry-pick of
several commits, if the lock stopped it partway through. Running it
again then fails because the operation is already in progress.
Add a hook that such a command can use to tell the runner what to do
instead. The following commits use it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The repository doesn't say how to report a vulnerability privately, and
#6185 was reported in a public issue. Point reporters to GitHub's
private vulnerability reporting.
The repository doesn't say how to report a vulnerability privately,
and #6185 was reported in a public issue. Point reporters to GitHub's
private vulnerability reporting.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
In the Commits panel, the "go to bottom" command (`>`) already has a
special case where it jumps to the beginning of the checked-out branch
first, and only then to the end of the list.
In this PR we take this one step further and also make it stop at the
beginning of each individual branch in a stack. This makes it easier to
navigate stacks of long branches.
Also, we make it stop at the beginning of the rebase todos in an
interactive rebase, and at the bad, current and good commits of a
bisect.
The divergence view shows the remote commits in a section above the
local ones. Pressing '>' now goes to the beginning of the remote section
before it goes on to the bottom of the local one.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
During a bisect, the commits panel shows the commits known to be bad at
the top, the known good ones at the bottom, and the ones that the bisect
hasn't ruled out yet between them. Pressing '>' now stops at the
bottommost bad commit, then at the commit to test, and then at the
topmost good commit.
It doesn't stop at each commit marked good. The commits between two of
them are all good, and they don't form a section of their own.
During a bisect, it also doesn't stop at the beginnings of the other
sections, such as the beginning of a branch. The commits panel doesn't
color the commits by whether they are merged while bisecting, so these
would look like arbitrary commits.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
In a stack of branches, pressing '>' in the commits panel went to the
beginning of the bottommost branch right away. Make it go to the
beginning of the branch that the selection is in first, and then to the
beginning of each branch below it. During a rebase, the update-ref todos
separate the branches among the todos, so stop above each of them too.
The branches of the stack are the ones that the commits list marks, and
that pushing and pulling a stack include.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
During a rebase, cherry-pick or revert, the todos are a section of their
own at the top of the commits panel. Pressing '>' now goes to the first
of them, the bottommost one, before it goes on to the beginning of the
branch.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The command went to the commit above the first merged one whenever the
commit below the selection wasn't merged. It did this even if the
selection was below that commit already.
Collect the places where the command can stop, and go to the closest one
below the selection, or to the bottom if there is none. This also makes
it easy to add more places to stop at.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If the history of a branch interleaves merged and unmerged commits, for
example because master was merged into the branch, pressing '>' on a
merged commit that an unmerged one follows selects a commit above it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The local commits and the sub-commits contexts had identical copies of
it. We are going to make it smarter, so make sure the copies don't
drift apart.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If a branch was merged into a local main branch, but the main branch
wasn't pushed yet, the commits list still marks the head of the branch
as part of a stack. For example, after merging wip into master locally,
the commits of master show a marker at the head of wip.
Pushing and pulling a stack leave such branches out since #6169, and the
markers disappear as soon as the main branch is pushed. Leave them out
of the markers too, so that the markers show the same stack.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The commits list will need this to decide which branches to mark. It
renders the list again whenever the selection changes, so stop the walk
at merged commits. Their parents are merged too, and a local main branch
is usually merged itself, so there is mostly nothing left to walk.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The commits list will need it to mark the branches of a stack, and so
will the "go to bottom" command of the commits panel to find their
beginnings. Neither the presentation nor the context package can import
helpers.
Rename it to BranchesBelow, since the name of the package says that it
is about stacks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If `.gitmodules` contains a submodule name like `../../../victim`,
removing that submodule in lazygit deletes the directory `victim` next
to the repository, along with everything in it. With enough `../`
components the path becomes `/`, and lazygit then deletes all files that
the user has permission to delete. An attacker only needs to commit such
a `.gitmodules` file to a repository. A user of that repository then
only has to remove the submodule in lazygit and confirm the prompt.
This happens because lazygit parses `.gitmodules` itself and uses the
names and paths in it without checking them. It deletes a submodule's
git dir with `os.RemoveAll`, joining `.git/modules` with the name, and
`filepath.Join` resolves the `..` components. Paths have a similar
problem. Lazygit runs some commands in the submodule's directory, so
with `path = ../other_repo` (or a symlink that points there), nuking the
working tree stashes the changes and untracked files of that other
repository. Git itself ignores such names (it prints "ignoring
suspicious submodule name"), and it only uses a path from `.gitmodules`
if its index has a submodule at that path.
This PR:
- Ignores submodules whose name fails git's own check in
`check_submodule_name()`: an empty name, or `..` as a component, with
both `/` and `\` counting as separators on every platform.
- Ignores submodules whose path isn't a directory inside the repository,
or whose path goes through a symlink.
- Refuses to remove a submodule whose git dir isn't below
`.git/modules`, before running any git command. This also catches the
name `.`, which git accepts. Removing a submodule with that name used to
delete the git dirs of all submodules.
- Anchors the regexes that parse `.gitmodules` at the start of a line.
This is unrelated to the security problem. A url containing `path=` was
taken for the submodule's path, and a commented-out section showed up as
a submodule.
Ignored entries no longer appear in the submodules list. Git doesn't
treat them as submodules either.
Fixes#6185.
If a submodule's url contains "path=", for example
"https://example.com/repo?path=other", lazygit takes "other" for the
submodule's path and loses the url. Also, a commented-out section in
.gitmodules shows up as a submodule.
The regexes that parse .gitmodules aren't anchored, so they find a key
or a section header anywhere in a line. Anchor them at the start of the
line.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If .gitmodules contains a submodule path like "../other_repo", nuking
the working tree in lazygit stashes all changes and untracked files of
that other repository. The same happens if the path is a symlink that
points to it. The changes can be recovered with "git stash pop" in that
repository, but the user has no reason to look there.
This happens because lazygit runs some commands in the submodule's
directory, and takes that directory from .gitmodules as it is. Git
itself only uses a path from .gitmodules if its index has a submodule
at that path, and such a path can't lead out of the repository.
Ignore a submodule unless its path is a directory below the directory
that contains the .gitmodules file, without any symlinks in between.
This also keeps GetConfigs from reading the same .gitmodules file again
and again for a path of ".".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Git accepts "." as a submodule name, and so does GetConfigs. Removing
such a submodule in lazygit deletes .git/modules, together with the git
dirs of all other submodules. Any unpushed commits in those submodules
are lost.
Check the path of the git dir before running any git command, and
refuse to remove the submodule if the path isn't below .git/modules.
This also protects against names with ".." components, in case one ever
gets past GetConfigs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If .gitmodules contains a submodule name like "../../../victim",
removing that submodule in lazygit deletes the directory "victim"
outside the repository, along with everything in it. With enough "../"
components the path becomes "/", and lazygit then deletes all files
that the user has permission to delete. An attacker only needs to
commit such a .gitmodules file to a repository. If a user of that
repository removes the submodule in lazygit, their files are gone.
This happens because lazygit deletes the submodule's git dir with
os.RemoveAll, and builds its path by joining .git/modules with the name
from .gitmodules. filepath.Join resolves the ".." components.
Git refuses to use such names. It prints "ignoring suspicious submodule
name" and treats the entry as if it didn't exist. Do the same in
GetConfigs, using the same rule as git's check_submodule_name().
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
So far, GetConfigs loaded the nested submodules of an entry as soon as
it saw the entry's path line. Parse the whole file first, and load the
nested submodules in a second loop. This prepares for checking the name
and path of each entry before using it.
This only makes a difference for malformed entries. If the path value
is empty, we no longer read the same .gitmodules file over and over.
If an entry has several path lines, we no longer load its nested
submodules several times.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Removing a submodule in a linked worktree deletes the git dir of that
submodule in the main worktree. This breaks the submodule there, and any
unpushed commits, local branches and stashes in it are lost. The git dir
of the submodule in the linked worktree stays behind.
Git keeps the git dirs of submodules separately for each worktree. For a
linked worktree, they are in `.git/worktrees/<worktree>/modules`.
Lazygit used the worktree's git dir until #3341 switched it to the
repo's git dir, so this has been broken since v0.41.0. This PR goes back
to using the worktree's git dir.
Removing a submodule in a linked worktree deletes the git dir of that
submodule in the main worktree. This breaks the submodule there, and
any unpushed commits, local branches and stashes in it are lost. The
git dir of the submodule in the linked worktree stays behind.
Git keeps the git dirs of submodules separately for each worktree. For
a linked worktree, they are in .git/worktrees/<worktree>/modules.
Lazygit used the worktree's git dir until 3b723282cb switched it to the
repo's git dir, so this has been broken since v0.41.0. Use the
worktree's git dir again.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
If a search match is in a commit below or above the visible area of the
commits panel, going to it with /, n or N doesn't scroll the panel
sideways to show it. The panel keeps the horizontal scroll position of
the previous match instead. Since this depends on whether the commit was
on screen before, it seems to happen only some of the time.
The commits panel renders only the lines on screen. So the search knows
where in a commit's line its match is only once the line is on screen,
and that happens after the search has scrolled the panel to it.
Scroll the panel sideways once more after rendering the lines that a
search has scrolled to. The same applies to the commits of a branch or
tag.
If a search match is in a commit below or above the visible area of the
commits panel, going to it with /, n or N doesn't scroll the panel
sideways to show it. The panel keeps the horizontal scroll position of
the previous match instead. Since this depends on whether the commit
was on screen before, it seems to happen only some of the time.
The commits panel renders only the lines on screen. So the search knows
where in a commit's line its match is only once the line is on screen,
and that happens after the search has scrolled the panel to it.
Scroll the panel sideways once more after rendering the lines that a
search has scrolled to. The same applies to the commits of a branch
or tag.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A view that renders only the lines on screen is going to need it once
it has rendered the line of a match.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
