Community
Participate
Working Groups
The commit dialog takes a long time to come up on large repositories. This is most likely due to scanning the working tree looking for untracked files. We should implement bug 309359 to support committing staged changes only and this should become the default (as in command line git). This would completely skip scanning for untracked files. In the commit dialog itself it should be ensured that: - show untracked files is 'off' by default - state of this setting is persisted When scanning for untracked files is "on" untracked files that should be ignored according to .gitignore should be ignored.
- use of deprecated GitIndex may also affect performance so if possible we should remove usages
*** Bug 334994 has been marked as a duplicate of this bug. ***
[Batch change] Remove passed Target Milestones If anyone on CC list is going to fix/implement this, feel free to assign a new, post-1.3/2.0, target milestone.
This bug is certainly one of the big reasons my Eclipse is useless with Git. Would love to see this fixed.
(In reply to comment #4) > This bug is certainly one of the big reasons my Eclipse is useless with Git. > Would love to see this fixed. did you try to use the staging view to commit changes ?
the situation has improved a lot with https://git.eclipse.org/r/#/c/6232/ for our ~1GB ~33.000 files repo it takes 1-5 seconds now, which is ok. Still, using the staging view (with https://git.eclipse.org/r/#/c/6328/) is the better solution for us, as you can type the message while staging files :)
Created attachment 217360 [details] Screenshot of the TortoiseGit Commit dialog (while loading)
Created attachment 217361 [details] Screenshot of the TortoiseGit Commit dialog (ready) TortoiseGit has a good approach to this problem (see attached screenshots). The commit dialog is displayed immediately allowing the user to type a comment without delay. The list of files is then loaded asynchronously in the background and displayed as soon as it's ready. This really boosts the user experience. 'Commit' is such a frequent operation that this small improvement in usability would be of huge value.
I'd also really like to see this concurrency feature being built in EGit! I currently do not use Eclipse to commit my files just because I do not like to wait for the dialog to appear. This really is a major drawback that seems to be fixable with bounded effort. I hope someone will proceed in working on this feature soon! Thanks in advance!
why don't you use the staging view? since the latest improvements, it's really well usable, especially for larger repositories - we're using it with a repo ~1GB and ~33000 files - works like a charm.
I'd like to select the projects/files/directories to commit in the Packet Explorer/Navigator. The Git Staging View could be wonderful but it seems not be be context sensitive to the project/file/directory selection - is there a way to make it sensitive to such a selection, e.g., like the filtering (by scope) of the Problems View? Another practicable way would be to drag files directly from the Packet Explorer into the Staged Changes List. This does not work in my EGit Version 1.3.0 (Feb, 2012) - should I update to the latest version?
On my repository, opening the commit dialog takes about 15 seconds, whereas git status takes less than 1 second. The performance of the staging view is not much better: it takes a long time to refresh, then it takes a long time to stage the files, and then it takes a long time to refresh again after I commit.
(In reply to comment #11) > Another practicable way would be to drag files directly from the Packet > Explorer into the Staged Changes List. This does not work in my EGit Version > 1.3.0 (Feb, 2012) - should I update to the latest version? That's not yet implemented. It's a good idea though, I opened bug 385412 for that.
The amount of time the commit dialog takes to open seems to be related to the number of projects one has imported from the repository. Is it possible that it is looking at each file produced by the build to determine whether it should ignore it, rather than first checking .gitignore to see which directories it can skip?
(In reply to comment #14) > The amount of time the commit dialog takes to open seems to be related to the > number of projects one has imported from the repository. Not just the time, but the number up to which the progress dialog counts, which I'm guessing might be files. If the number of files being looked at depends on which projects have been imported, it seems like it must be looking at files produced by the Eclipse build.
The commit dialog is insanely much faster since 2.3.
Indeed it is! :)
