Community
Participate
Working Groups
Currently EGit holds a workspace lock during the complete pull operation. Suggestion is to avoid this during the fetch. Detailed information from Matthias Sohn ------------------------------------- EGit's PullOperation calls JGit's PullCommand. Pull consists of a fetch command followed by a merge or rebase command. Typically fetch takes much longer than merge or rebase so instead of pessimistically locking the affected projects for the complete runtime of a pull command we could run fetch without any scheduling rule (fetch doesn't modify files in the workspace but only downloads new git objects) then acquire the lock on the affected projects and if this succeeds run the merge or rebase command. If we can't get the lock we would need to fail the lock and ask the user to retry later. This could be implemented in EGit by running JGit FetchCommand followed by a MergeCommand or RebaseCommand. Alternatively we could enhance JGit's PullCommand with a callback enabling EGit to acquire the lock after fetch finished and before merge/rebase is started. ------------------------------------
Today using pull from Eclipse is impossible (maybe slow network today?) as it takes very long and the IDE is unusable during the pull operation. Currently have to use the pull operation via the command line.
@Lars I'm doing many git-pull's over the day and currently I can't see any real blocking. The result-dialog is also not-modal so this is good too :)
(In reply to Andreas Hoehmann from comment #2) > @Lars I'm doing many git-pull's over the day and currently > I can't see any real blocking. Blocking depends on network and repo size.
Created attachment 278363 [details] Screencast Here is a tiny fraction of the wait process I see the whole day, once pulling.
Thomas, WDYT?
(In reply to Lars Vogel from comment #5) > Thomas, WDYT? Sure, would be good. But difficult to get right, especially for multi-pull on several repositories.
