Rebase dialog is very slow on confict during big rebase #11196
Labels
type: git issue
Issues that attributable to git
Comments
|
This need to be directed to Git, the GUI cannot speed up Git itself. |
gerhardol
added
type: git issue
|
Git is fast IMO, if there is no conflict, rebase runs fast. But loading dialog content is very slow. Probably rendering commits in Rebase dialog... doing rebase from cmd without GitExtensions is fast. |
|
More or less a duplicate of #10698 |
|
@dosercz Is it for a rebase or an interactive rebase? or both? |
|
It happens to me during an interactive rebase. I'm using it in most cases... |
Indeed, duplicate of this one. Let's close this one and continue the discussion on the other one (as I have a PoC giving interesting results) |
pmiossec
added a commit
to pmiossec/gitextensions
that referenced
this issue
Sep 7, 2023
by retrieving all the commits data with only one `git log` call instead of one by commit. It is possible as when rebasing, all the commits belong to the same branch. Kept a fall back to previous way to retrieve commit data for 1 commit if commit is not in the one loaded. Fixes gitextensions#10698 and gitextensions#11196
pmiossec
added a commit
to pmiossec/gitextensions
that referenced
this issue
Sep 7, 2023
by retrieving all the commits data with only one `git log` call instead of one by commit. It is possible as when rebasing, all the commits belong to the same branch. Kept a fall back to previous way to retrieve commit data for 1 commit if commit is not in the one loaded. Results with 7448 commits rebased: 2s instead of 4m50 previously Fixes gitextensions#10698 and gitextensions#11196
pmiossec
added a commit
to pmiossec/gitextensions
that referenced
this issue
Sep 7, 2023
by retrieving all the commits data with only one `git log` call instead of one by commit. It is possible as when rebasing, all the commits belong to the same branch. Kept a fall back to previous way to retrieve commit data for 1 commit if commit is not in the one loaded. Results with 7448 commits rebased: 2s instead of 4m50 previously Fixes gitextensions#10698 and gitextensions#11196
ghost
added
the
pmiossec
added a commit
to pmiossec/gitextensions
that referenced
this issue
Sep 14, 2023
by retrieving all the commits data with only one `git log` call instead of one by commit. It is possible as when rebasing, all the commits belong to the same branch. Kept a fall back to previous way to retrieve commit data for 1 commit if commit is not in the one loaded. and read bodies of all rebased commits (even the ones older than 6 monthes like it was the case before. RevisionReader had to be adapted to do that.) Results with 7448 commits rebased: 2s instead of 4m50 previously Fixes gitextensions#10698 and gitextensions#11196
pmiossec
added a commit
that referenced
this issue
Sep 15, 2023
by retrieving all the commits data with only one `git log` call instead of one by commit. It is possible as when rebasing, all the commits belong to the same branch. Kept a fall back to previous way to retrieve commit data for 1 commit if commit is not in the one loaded. and read bodies of all rebased commits (even the ones older than 6 monthes like it was the case before. RevisionReader had to be adapted to do that.) Results with 7448 commits rebased: 2s instead of 4m50 previously Fixes #10698 and #11196
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
Issue description
I'm making interactive rebase of a lot of commits (approx 1000) and if there is a conflict and Rebase dialog is opened whole GUI is frozen for 1+ minute.
It depends on number of rebased commits. If there are only few commits, it's not a problem. But with increasing number of commits it takes more time to open dialog.
Steps to reproduce
Did this work in previous version of GitExtensions?
No
Diagnostics
No response
The text was updated successfully, but these errors were encountered: