| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- **PR Description**
Adds a new option `git.comitPrefix` to act similarly to
`git.commitPrefixes`, except, if defined, it applies to any repo that
doesn't have an entry in `git.commitPrefixes`.
- **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] Docs (specifically `docs/Config.md`) have been updated if
necessary
* [x] You've read through your own file changes for silly mistakes etc
|
|
|
|
- **PR Description**
In the "View divergence from upstream" view we have so far disabled the
commit graph because it was too difficult to implement properly. I
really miss it though, so here's a PR that enables it there, too.
For feature branches it is not essential, because these usually don't
contain merges and the graph is a trivial line. However, for the master
branch against its upstream it is useful too see how many PRs were
merged since you last fetched it, and the graph helps a lot with that.
Also, when we implement #3536 it will be very useful there, too.
|
|
|
|
- **PR Description**
fix some comments and typos
|
|
Signed-off-by: knowmost <knowmost@outlook.com>
|
|
- **PR Description**
Add a new config option `gui.commitHashLength` to change the length of
the commit hash displayed in commits view.
default:
<img width="472" alt="image"
src="https://github.com/jesseduffield/lazygit/assets/98684296/36dced1e-0c74-4dbd-8670-98e17a75d83a">
With config:
```yaml
gui:
commitHashLength: 3
```
<img width="463" alt="image"
src="https://github.com/jesseduffield/lazygit/assets/98684296/e8023cd8-f138-4af8-ae0e-3661f80206ca">
- Changes
- Added the user config option to to `pkg/config/user_config.go` and
`schema/config.json`
- documented in `docs/Config.md`
- Changed the code that displays the hash in
`pkg/gui/presentation/commits.go`
---
- **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))
* [x] Docs (specifically `docs/Config.md`) have been updated if
necessary
* [x] You've read through your own file changes for silly mistakes etc
|
|
Change `func displayCommit()` so all the individual strings are built first,
then the whole thing `cols` is put together. Before, most strings were built
prior to constructing `cols`, but a few were built inside the `cols`
construction.
|
|
- Add config option `commitHashLength` to to pkg/config/user_config.go
- Changed the hash display in pkg/gui/presentation/commits.go
|
|
- **PR Description**
Support `git.paging.externalDiffCommand` config in diffing mode (i.e.
when showing the diff between two commits using `W`).
Fixes #3518.
|
|
|
|
|
|
|
|
|
|
|
|
- **PR Description**
The rebase.updateRefs feature of git is very useful to rebase a stack of
branches and keep everything nicely stacked; however, it is usually in
the way when you make a copy of a branch and want to rebase it "away"
from the original branch in some way or other. For example, the original
branch might sit on main, and you want to rebase the copy onto devel to
see if things still compile there. Or you want to do some heavy history
rewriting experiments on the copy, but keep the original branch in case
the experiments fail. Or you want to split a branch in two because it
contains two unrelated sets of changes; so you make a copy, and drop
half of the commits from the copy, then check out the original branch
and drop the other half of the commits from it.
In all these cases, git's updateRefs feature insists on moving the
original branch along with the copy in the first rebase that you make on
the copy. I think this is a bug in git, it should create update-ref
todos only for branches that point into the middle of your branch
(because only then do they form a stack), not when they point at the
head (because then it's a copy). I had a long discussion about this on
the git mailing list [1], but people either don't agree or don't care
enough.
So we fix this on our side: whenever we start a rebase for whatever
reason, be it interactive, non-interactive, or behind-the-scenes, we
drop any update-ref todos that are at the very top of the todo list,
which fixes all the above-mentioned scenarios nicely.
I will admit that there's one scenario where git's behavior is the
desired one, and the fix in this PR makes it worse: when you create a
new branch off of an existing one, with the intention of creating a
stack of branches, but before you make the first commit on the new
branch you realize some problem with the first branch (e.g. a commit
that needs to be reworded or dropped). It this case you do want both
branches to be affected by the change. In my experience this scenario is
much rarer than the other ones that I described above, and it's also
much easier to recover from: just check out the other branch again and
hard-reset it to the rebased one.
[1]
https://public-inbox.org/git/354f9fed-567f-42c8-9da9-148a5e223022@haller-berlin.de/
|
|
The rebase.updateRefs feature of git is very useful to rebase a stack of
branches and keep everything nicely stacked; however, it is usually in the way
when you make a copy of a branch and want to rebase it "away" from the original
branch in some way or other. For example, the original branch might sit on main,
and you want to rebase the copy onto devel to see if things still compile there.
Or you want to do some heavy history rewriting experiments on the copy, but keep
the original branch in case the experiments fail. Or you want to split a branch
in two because it contains two unrelated sets of changes; so you make a copy,
and drop half of the commits from the copy, then check out the original branch
and drop the other half of the commits from it.
In all these cases, git's updateRefs feature insists on moving the original
branch along with the copy in the first rebase that you make on the copy. I
think this is a bug in git, it should create update-ref todos only for branches
that point into the middle of your branch (because only then do they form a
stack), not when they point at the head (because then it's a copy). I had a long
discussion about this on the git mailing list [1], but people either don't agree
or don't care enough.
So we fix this on our side: whenever we start a rebase for whatever reason, be
it interactive, non-interactive, or behind-the-scenes, we drop any update-ref
todos that are at the very top of the todo list, which fixes all the
above-mentioned scenarios nicely.
I will admit that there's one scenario where git's behavior is the desired one,
and the fix in this PR makes it worse: when you create a new branch off of an
existing one, with the intention of creating a stack of branches, but before you
make the first commit on the new branch you realize some problem with the first
branch (e.g. a commit that needs to be reworded or dropped). It this case you do
want both branches to be affected by the change. In my experience this scenario
is much rarer than the other ones that I described above, and it's also much
easier to recover from: just check out the other branch again and hard-reset it
to the rebased one.
[1]
https://public-inbox.org/git/354f9fed-567f-42c8-9da9-148a5e223022@haller-berlin.de/
|
|
branches
These tests succeed here, but have comments explaining which bits are undesired.
See next commit for a more detailed explanation why.
|
|
Sometimes it takes a while to get PRs accepted upstream, and this blocks our
progress. Since I'm pretty much the only one making changes there anyway, it
makes sense to point to my fork directly.
|
|
It was added in 2018 (700f8c7e796), but I don't know for what purpose. It just
took me 15 minutes to figure out why my new file todo.go wasn't added, so I'm
removing this entry as I find it more harmful than helpful.
|
|
- **PR Description**
Resolves https://github.com/jesseduffield/lazygit/issues/3421
The error is "Expected exactly one original SHA, found 0" but the merge
commit hash (`d6a7a04c626e40071133de26ebe8fdd225caa5c0`) is present in
the rebase TODO file.
However, the commit is missed during search because the filter is only
looking for pick commits:
https://github.com/jesseduffield/lazygit/blob/580818e935e19a67f7fe1bbb148224a95781879c/pkg/utils/rebase_todo.go#L238
Checking for merge commits as well fixes the issue.
I believe only pick and merge should be valid here. If already in an
interactive rebase, lazygit only allows amending to the current HEAD
commit. When that happens, this whole interactive rebase logic is
bypassed and lazygit just performs `git commit --amend`:
https://github.com/jesseduffield/lazygit/blob/580818e935e19a67f7fe1bbb148224a95781879c/pkg/gui/controllers/local_commits_controller.go#L668
This is the reason why amending to a HEAD merge commit currently works
whereas non-HEAD does not.
|
|
|
|
|
|
Signed-off-by: thirdkeyword <fliterdashen@gmail.com>
|
|
- **PR Description**
Simplify and canonicalize error handling across the code base.
Previously it was important to make sure that errors don't bubble up
into gocui, because it would panic there; so we had to show errors in
error panels in the right places (in controller code, usually). This is
error-prone because it's easy to forget (see #3490 for an example);
also, it's not always obvious where in the call chain the error panel
needs to be shown. Most of the time it's in controller code, but we had
plenty of calls to `Error()` in helpers, and I remember that I found
this very confusing when I was new to the code base.
Change this so that you can simply return errors everywhere. The
functions to show an error message manually have been removed for
clarity.
I tried to structure the commits so that you can review them one by one.
Closes #3491.
|
|
There is no reason any more for application code to show error messages in a
panel. Just return an error instead.
|
|
It is now only used as the error handler that is passed to gocui.Gui on
construction; it's not a client-facing API any more. Also, it doesn't have to
handle gocui.ErrQuit, as gocui takes care of that.
|
|
|
|
We are already doing this in other cases in this file.
|
|
This lets us get rid of a few more calls to Error(), and it simplifies things
for clients of OnWorker: they can simply return an error from their callback
like we do everywhere else.
|
|
|
|
Now that we have an error handler set, we can simply let them bubble up all the
way to gocui.
|
|
|
|
In Gui.onWorker we only make the minimum possible change to get things to
compile after the API-breaking change of the gocui update; we'll make this
cleaner later in this branch.
|
|
It doesn't seem to be used.
|
|
Automated changes by
[create-pull-request](https://github.com/peter-evans/create-pull-request)
GitHub action
|
|
|
|
- **PR Description**
- **Please check if the PR fulfills these requirements**
* [ ] Cheatsheets are up-to-date (run `go generate ./...`)
* [ ] 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))
* [ ] Docs (specifically `docs/Config.md`) have been updated if
necessary
* [ ] 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**
Uses [this popular-ish
action](https://github.com/marketplace/actions/create-pull-request) to
create a PR.
> How the action behaves:
>
> If there are changes (i.e. a diff exists with the checked-out base
branch), the changes will be pushed to a new branch and a pull request
created.
> If there are no changes (i.e. no diff exists with the checked-out base
branch), no pull request will be created and the action exits silently.
> If a pull request already exists it will be updated if necessary.
Local changes in the Actions workspace, or changes on the base branch,
can cause an update. If no update is required the action exits silently.
> If a pull request exists and new changes on the base branch make the
pull request unnecessary (i.e. there is no longer a diff between the
pull request branch and the base), the pull request is automatically
closed. Additionally, if
[delete-branch](https://github.com/marketplace/actions/create-pull-request#delete-branch)
is set to true the branch will be deleted.
Demo Action Run:
https://github.com/SachinVin/lazygit/actions/runs/8675283475
Demo PR: https://github.com/SachinVin/lazygit/pull/2
You also might want to consider changing this action to trigger as a
cron job instead on pushes to master.
- **Please check if the PR fulfills these requirements**
* [ ] Cheatsheets are up-to-date (run `go generate ./...`)
* [ ] 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))
* [ ] Docs (specifically `docs/Config.md`) 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
-->
|
|
|
|
Standardise on use of 'commit hash' rather than 'commit SHA'
Close: https://github.com/jesseduffield/lazygit/issues/3208
|
|
We achieve this by wrapping the model Commit in a custom struct that provides
both.
|
|
Useful as a regression test to check that the following commit doesn't break it.
|
|
|
|
|
|
|
|
|
|
|
