Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[egit-dev] locking mechanism


On 20.12.13 09:04, "Robin Rosenberg" <robin.rosenberg@xxxxxxxxxx> wrote:

>
>I never (well rarely) just commit. Autostaging in delete/rename means I
>have to make fewer adjustments in the normal case than without. Not doing
>it for new files is because the workspace often constains crap that should
>not be added. NOT for any other reason. git mv and git rm also autostages,
>so there is no inconsistency in that sense.

I agree that adding new files automatically is totally different from
adding deletions
or moves automatically due to the very same reason (that the workspace
often contains 
many files not belonging to the repo). And autostaging moves is a way to
mimic the 
behavior of git mv, where Egit doesn't offer a similar feature. Git mv
ensures that the user
does not forget to commit both deletion and add at once. Often moving or
renaming files
is not explicitly triggered by the user but by the tooling itself, e.g.
during refactoring.

So I would propose to leave this default like it is, but nevertheless add
a new 
preference to switch off auto staging as proposed in Bug 341322.



But this preference wouldn't help Laurent in his problem of locking. We
cannot tell the user
that model merge only works when this preference is set.

A quick solution to solve this problem could be to add a flag to the
GitMoveDeleteHook to
switch off auto staging programmatically. But this seems more like a hack
for this concrete problem
which may even cause additional problems, e.g. with threading behavior.

A better solution would be to implement a reentrant DirCache lock as
Laurent proposed already.
The method DirCache.lock could check if it was already called in the stack
of the thread and 
in that case just return the instance which was created in a
previous call in this thread. Only the last unlock call would delete the
lock file.

I propose that we discuss this on the jgit mailing list.


Stefan 



Back to the top