This makes it easier to use the full ref in the git merge-base call, which
avoids ambiguities when there's a tag with the same name as the current branch.
This fixes a hash coloring bug in the local commits panel when there's a tag
with the same name as the checked out branch; in this case all commit hashes
that should be yellow were painted as red.
GetMergeBase is always called with a full ref, so it shouldn't need the
ignoringWarnings hack (which is about ignoring warnings coming from ambiguous
refs).
Also, separate stdout and stderr, which would also have solved the problem. We
no longer really need it now, but it's still cleaner.
- **PR Description**
I didn't enable the `showDivergenceFromBaseBranch` config by default yet
(even though I find it very useful) because I'm worried that people
might find the display too noisy. Drawing the divergence information
right-aligned helps reduce that noise a little bit.
- **PR Description**
In the Go 1.21 standard library, a new function has been introduced that
enhances code conciseness and readability. It can be find
[here](https://pkg.go.dev/slices@go1.21.1#Equal).
- **PR Description**
This is very similar to what we did for pressing space in #4386; we
forgot that the "stage all" command has the same issue.
Also, fix two other commands that stage all files under the hood:
- when continuing a rebase after resolving conflicts, we auto-stage all
files, but in this case we never want to include untracked files,
regardless of the filter
- likewise, pressing ctrl-f to find a base commit for fixup stages all
files for convenience, but again, this should only stage files that are
already tracked
Also, fix two other commands that stage all files under the hood:
- when continuing a rebase after resolving conflicts, we auto-stage all files,
but in this case we never want to include untracked files, regardless of the
filter
- likewise, pressing ctrl-f to find a base commit for fixup stages all files for
convenience, but again, this should only stage files that are already tracked
- **PR Description**
This way we don't have to update the text and all translations every
time we bump the version.
Remove the year from the error text, it's cumbersome to update and I
don't find it very important to have in the message.
Also remove the invitation to file an issue; I don't find it very likely
that we are going to relax the minimum git requirement again.
This way we don't have to update the text and all translations every time we
bump the version.
Remove the year from the error text, it's cumbersome to update and I don't find
it very important to have in the message.
Also remove the invitation to file an issue; I don't find it very likely that we
are going to relax the minimum git requirement again.
- **PR Description**
In #4663 we added information in the tags panel about the selected tag
(whether it's annotated etc). Unfortunately this introduced a
performance regression in repositories with many tags, so revert this
and implement the feature in a slightly different way to avoid the
performance hit.
Fixes#4770.
It seems that `git for-each-ref` is a lot slower than `git tag --list` when
there are thousands of tags, so revert back to the previous method, now that we
no longer use the IsAnnotated field.
This reverts commit b12b1040c3.
Storing it in the Tag struct makes loading tags a lot slower when there is a
very large number of tags; so determine it on the fly instead. On my machine,
the additional call takes under 5ms, so it seems we can afford it.
These should have been added when we started rendering this information in
e5b09f34e0; apparently I was too lazy back then. Adding them now to guard
against breaking it in the next commit.
I'm adding these to the CRUD tests, it doesn't seem worth adding separate tests
just for these assertions.
- **PR Description**
Fixes an index out of bounds panic that occurs when lazygit starts up in
repositories with a large number of tags on a single commit.
When a commit has thousands of tags, the git log output can become
malformed or truncated, causing the `extractCommitFromLine` function to
receive fewer than the expected 8 null-separated fields. This results in
an index out of bounds panic when trying to access `split[5]` and
beyond.
Closes#4765
Like message, extraField can get very long (when there are thousands of tags on
a single commit), so move it to the end; this allows us to truncate overly long
lines in the output and still get all the essential fields.
Co-authored-by: Stefan Haller <stefan@haller-berlin.de>
- **PR Description**
Rewording or dropping commits was disabled when filtering commits by
path or author. This used to be necessary a long time ago for technical
reasons, but these reasons went away with the merge of #2552, so enable
them now.
Technically we could enable a few more, but I chose not to because some
might be surprising or confusing in filtering mode. For example,
creating a fixup commit would work (shift-F), but the newly created
commit might not show up if it doesn't match the filter. Similarly,
pressing `f` to fixup a commit into its parent would work, but that
parent commit might not be visible, so users might expect to be fixing
up into the next visible commit.
Fixes#2554.
There's no reason not to allow these.
Technically we could enable a few more, but I chose not to because some might be
surprising or confusing in filtering mode. For example, creating a fixup commit
would work (shift-F), but the newly created commit might not show up if it
doesn't match the filter. Similarly, pressing `f` to fixup a commit into its
parent would work, but that parent commit might not be visible, so users might
expect to be fixing up into the next visible commit.
- **PR Description**
Show the `[0]` keybinding in the title of the main view, to make it more
discoverable.
Also, move it to the "global" section of the keybindings menu.
And several minor fixes and cleanups, see individual commits for
details.
Fixes#4738.
We show it only if the "showPanelJumps" config is on, although the
focus-main-view command is not technically part of the panel jump keys; but it
looks similar.
I left this out originally because it's not needed for the status "dashboard"
view (except on really tiny screens); however, it *is* useful after pressing `a`
to show the all branches log, and even more so for people who use the
"statusPanelView: allBranchesLog" config. And it doesn't really hurt for the
dashboard view either, so just enable it always rather than making a distinction
which view we are showing.
This is not a behavior change, we already include these in the menu, but that's
because of a bug that we will fix in the next commit.
I find it useful to see these commands, especially for rarely-used custom
commands that you don't want to waste a keybinding on.
- **PR Description**
When entering staging (or patch building) for an added or deleted file,
it doesn't make sense to use hunk mode, because pressing space would
stage/unstage the entire file, and if the user wanted to do that, they
would have pressed space in the Files panel. So always use line mode for
added/deleted files by default, even if the useHunkModeInStagingView
user config is on.
When entering staging (or patch building) for an added or deleted file, it
doesn't make sense to use hunk mode, because pressing space would stage/unstage
the entire file, and if the user wanted to do that, they would have pressed
space in the Files panel. So always use line mode for added/deleted files by
default, even if the useHunkModeInStagingView user config is on.
Not because it's terribly important to test here (doesn't hurt though), but
because it will be useful in the next commit for a new test we're adding there.
- **PR Description**
When filtering by file path for a file that was renamed at some point,
we show all commits even before the rename, which is great; however when
you selected a commit before the rename, the diff was empty. The commit
for the rename itself would show the file as added rather than renamed.
This PR fixes that; along the way, we fix the filtered reflog display,
which is supposed to filter by path like the commits view does, but this
didn't work.
Fixes#4510.
When shift-selecting a range of commits across a file rename in
filtering-by-path mode, the diff currently shows an added file rather than a
renamed file. Add a test that demonstrates this, we'll fix this in the next
commit.
When filtering for a file path we use the --follow option for "git log", so it
will follow renames of the file, which is great. However, if you then selected
one of the commits before a rename, you didn't see a diff, because we would pass
the original filter path to the "git show" call.
To fix this, call git log with the --name-status option when filtering by path,
so that each commit reports which file paths are touched in this commit;
remember these in the commit object, so that we can pass them to the "git show"
call later.
Be careful not to store too many such paths unnecessarily. When filtering by
folder rather than file, all these paths will necessarily be inside the original
filter path, so detect this and don't store them in this case.
There is some unfortunate code duplication between loading commits and loading
reflog commits, which I am too lazy to clean up right now.
These are very similar in that they call RunAndProcessLines on a git log command
and then process lines to create commits. Extract this into a common helper
function. At the moment this doesn't gain us much, but in the next commit we
will extend this helper function considerably with filter path logic, which
would otherwise have to be duplicated in both places.
It is good practice to use a -- argument even if no further arguments follow.
Doesn't really make a difference for this particular command though, I think.
I don't know why this function argument was added, but I don't like unnecessary
indirections, so I'm removing it as SubCommitsHelper has access to everything it
needs to do it itself.
Recycle reflog commits only for the non-filtered ones.
If we're not filtering, FilteredReflogCommits and ReflogCommits are the same. If
we then enter filtering and get reflog entries again, and pass a
lastReflogCommit, we'd recycle the previous FilteredReflogCommits, which are
unfiltered, so that's no good. Work around this by simply never using the
recycle mechanism when getting the filtered reflog commits.
We could do better by remembering what the last filter path or author was, and
only suppressing the recycling when it changed; but that's more complexity than
I want to add, so hopefully this is good enough.
Using the filtered one is probably not a good idea. It didn't do much harm
because the split of ReflogCommits and FilteredReflogCommits doesn't really work
right now (FilteredReflogCommits is always the same as ReflogCommits, even in
filtering mode), but we'll fix this in the next commit.
I can only guess what happened here: in aa750c0819, this code to manually load
the reflog commits was added, to make sorting branches by recency work when the
reflog is filtered by path. At that time we didn't have separate ReflogCommits
and FilteredReflogCommits models yet. Then, FilteredReflogCommits was introduced
(in 8822c409e2), probably for the very purpose of being able to get rid of this
again; but then it was forgotton to actually get rid of it.
The funny thing is that the introduction of FilteredReflogCommits happened in
the very next commit, 15 minutes later.
The test shows that selecting a commit before the rename shows an empty diff,
and selecting the rename itself shows an added file rather than a rename.
This broke with the introduction of the age in the stashes list in bc330b8ff3
(which was included in 0.41, so 12 minor versions ago).
This makes it work again when filtering by file, but it still doesn't work when
filtering by folder (and never has). We'll fix that next.
This was not a good idea, and it seems it has never been tested: the --name-only
and -z options don't work well together. Specifically, -z seems to simply cancel
--name-only.
This is not enough to make it work, we'll need more fixes in the next commit.
This reverts commit 50044dd5e0.
