[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [egit-dev] Expected performance profile of staging changes and committing then
|
On 11/06/2012 06:00 PM, Matthias Sohn wrote:
> 2012/11/6 Markus Duft <markus.duft@xxxxxxxxxx <mailto:markus.duft@xxxxxxxxxx>>
>
[snip]
>
>
> we need to keep the ability to do a full refresh also for the case when some git operations are done by
> another process than the Eclipse instance we are looking at. E.g. you may want to do some advanced
> git operations not yet available in EGit using native git which won't send these events.
I understand the problem you're talking about, but i don't see how this would interfere with this code? you mean if the index does not change, but only files on disc change externally? This would only be detected by a full refresh then, right? is there another way to detect it?
I now did a second (little different) implementation, which i like better, since it does not actually change JGit, but only the IndexDiffCacheEntry to fix the local performance issue. Please tell me which one you like better, and i will try to get production quality on that version then :D
Either these two (from yesterday):
[1] https://git.eclipse.org/r/#/c/8535/
[2] https://git.eclipse.org/r/#/c/8536/
Or this single on (from today):
[1] https://git.eclipse.org/r/#/c/8558/
For the second one i have a slightly better feeling about things like synchronization, and stability/reliability.
Markus
>
> --
> Matthias