Projects causes GIT to crash frequently during merge/rebase

[GoogleCodeExporter]

-- Projects 1.5 --

What steps will reproduce the problem?
1. Start with a project that is a git repository
2. Expand some directory nodes in the Projects tree for that project
3. Outside of editra, do a `git rebase` command (or similar command that 
causes multiple rapid updates to the project)

What is the expected output?
git rebase finishes successfully and the Projects plugin updates to show 
the new tree.

What do you see instead?
git rebase fails with:

  fatal: Unable to create '.git/index.lock': File exists.

  If no other git process is currently running, this probably means a git 
process crashed in this repository earlier. Make sure no other git process 
is running and remove the file manually to continue.

This doesn't always happen, but with a medium/large rebase (10+ changesets 
with several files changed in each) it almost always happens.

It never happens if Editra isn't running, or if the tree for the project is 
collapsed.

I assume the cause is the Projects plugin attempts to update the tree after 
each file change, rather than all at once after git rebase has finished. 
For some reason this causes the .git/index.lock file to persist just a 
fraction longer than it normally would, and that screws up GIT's subsequent 
operations.

Versions:
Editra 0.5.32
GIT 1.6.3.2
Ubuntu 8.10
Python 2.5.2
wxGTK 2.8.8.0

Original issue reported on code.google.com by craig.ds@gmail.com on 20 Jan 2010 at 9:09

[GoogleCodeExporter]

Hi,

Its possible, the status checks are issued when the projects plugin detects 
that a
file that is currently displayed has been modified on disk. This could probably 
be
optimized by setting a timer and not issuing the command until the updates have
stopped for a certain period of time.

I hope someone who uses git more frequently would re-write the projects support 
for
it as I don't feel that it is very robust right now. GIT does not produce very 
nice
to work with console output so it is difficult to parse and work with reliably.

I can look at adding the timer to control the status frequency which should help
minimize this situation but I think that the root cause is the inefficiency in 
the
projects GIT implementation since it needs to make multiple git calls in order 
to
gather the necessary status information.

Cody

Original comment by CodyPrec...@gmail.com on 21 Jan 2010 at 1:10

• Changed state: Accepted

[GoogleCodeExporter]

So the cause is the Projects plugin issuing git commands to check file status?

In that case, adding an option to disable VCS integration could be a good 
fix/workaround. I for one prefer to do my svn/git stuff from the command line 
anyway. 

I guess that would be implemented as a checkbox 'Enable source control 
integration' 
in the Source Control tab of the Projects configuration window.

Would that be okay? If so I'll make a new ticket and maybe I'll even get around 
to 
submitting a patch.

Original comment by craig.ds@gmail.com on 21 Jan 2010 at 1:24

[GoogleCodeExporter]

That would be my guess, as to why GIT has a lock file for running status checks 
is
another question since status checks shouldn't need to modify anything it seems 
odd
that there is a lock file.

Yea I could see having an option to disable the source integration could be 
usefull.
It should be implemented on a per control system basis defaulting to On. This 
way it
will be possible to disable it for individual systems which could offer some 
minor
performance improvements since as part of the discovery mechanism it will 
iterate
through each system till it finds one that matches the project directory.

While on this topic is there a GIT command that lists the status of a directory
showing the status of all files, bonus points if it includes files that are not 
under
control and/or full paths?

Cody

Original comment by CodyPrec...@gmail.com on 21 Jan 2010 at 1:58