Re: [egit-dev] Relationship of Pulling and Open Project

[Matthias Sohn <matthias.sohn@xxxxxxxxx>]

On Wed, Dec 21, 2016 at 4:04 PM, Lars Vogel <lars.vogel@xxxxxxxxxxx> wrote:

Dear EGit developer,

I noticed that I cannot open a closed project during a Git Pull
operation. See screenshot.

Is this intended or a undesired side effect?

EGit's PullOperation locks all projects versioned in the repository (ies) the operation was started for.

Project.open tries to obtain the same lock (IResourceRuleFactory.modifyRule(this)) and hence has to wait.

EGit locks the projects since 

- pull typically modifies files in the affected projects and could interfere with other jobs which also modify files in the same projects  

- operations modifying the git index of the same repository can't run concurrently.

The latter is also ensured by JGit by locking the index file.

The advantage of this pessimistic locking is that we prevent partial execution of the pull operation.

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.

-Matthias