workarounds to avoid confusing NetBeans or nbgit?

[Core]

The 0.3 release looks good.

I've started playing with nbgit again. I looked at nbgit earlier in
the year before I really understood Git and was afraid to use nbgit
because of not yet implemented features. But now that I realize I can
invoke Git commands outside nbgit in the meantime, so I'm ready to
really try to use it on something serious.

How does nbgit play nicely with changes that are happening outside its
control? Basically, what are the workarounds to avoid confusing
NetBeans or nbgit until features like checkout/push/pull/merge are
working? For example, what else should I do before or after invoking
a "custom action" to avoid problems?

[marc]

Core wrote:

> How does nbgit play nicely with changes that are happening outside its
> control? Basically, what are the workarounds to avoid confusing
> NetBeans or nbgit until features like checkout/push/pull/merge are
> working? For example, what else should I do before or after invoking
> a "custom action" to avoid problems?

It works fine, but takes ages -- think netbeans scanning hell without
the disk thrashing -- to get itself back in line after doing an external
git commit. (Ininitiate this via /git/status in nb) All you, the
user, wants, is for the little blue icons to disappear.

This seems like such a simple use case -- like scanning hell! -- that
it's confusing why it needs to do so much work.

--
Best,
Marc

"Change requires small steps."

[Jonas Fonseca]

On Thu, Oct 29, 2009 at 03:41, marc <gm...@auxbuss.com> wrote:
>
> Core wrote:
>
>> How does nbgit play nicely with changes that are happening outside its
>> control?  Basically, what are the workarounds to avoid confusing
>> NetBeans or nbgit until features like checkout/push/pull/merge are
>> working?  For example, what else should I do before or after invoking
>> a "custom action" to avoid problems?
>
> It works fine, but takes ages -- think netbeans scanning hell without
> the disk thrashing -- to get itself back in line after doing an external
> git commit. (Ininitiate this via /git/status in nb) All you, the
> user, wants, is for the little blue icons to disappear.

Somebody requested that a 'Refresh' action was added to the Git menu.
It might simplify this use case considerable. And for custom actions a
checkbox could be added to automatically refresh after running the
external command.

See issue 54 to star, comment etc.:
- http://code.google.com/p/nbgit/issues/detail?id=54

> This seems like such a simple use case -- like scanning hell! -- that
> it's confusing why it needs to do so much work.

The current way it is implemented can probably be improved a lot. In
the worst case (I didn't actually look into this yet), the plugin can
request refreshing of single files, meaning that JGit will do all the
initialization diffing the index and throw away most of the work. What
we should do of course is to improve the background refreshing task to
batch stuff together and reduce the amount of wasted work.

--
Jonas Fonseca

[marc]

Jonas Fonseca wrote:

>
> On Thu, Oct 29, 2009 at 03:41, marc <gm...@auxbuss.com> wrote:
>>
>> Core wrote:
>>
>>> How does nbgit play nicely with changes that are happening outside its
>>> control?  Basically, what are the workarounds to avoid confusing
>>> NetBeans or nbgit until features like checkout/push/pull/merge are
>>> working?  For example, what else should I do before or after invoking
>>> a "custom action" to avoid problems?
>>
>> It works fine, but takes ages -- think netbeans scanning hell without
>> the disk thrashing -- to get itself back in line after doing an external
>> git commit. (Ininitiate this via /git/status in nb) All you, the
>> user, wants, is for the little blue icons to disappear.
>
> Somebody requested that a 'Refresh' action was added to the Git menu.
> It might simplify this use case considerable. And for custom actions a
> checkbox could be added to automatically refresh after running the
> external command.
>
> See issue 54 to star, comment etc.:
> - http://code.google.com/p/nbgit/issues/detail?id=54

That'd be great.

>> This seems like such a simple use case -- like scanning hell! -- that
>> it's confusing why it needs to do so much work.
>
> The current way it is implemented can probably be improved a lot. In
> the worst case (I didn't actually look into this yet), the plugin can
> request refreshing of single files, meaning that JGit will do all the
> initialization diffing the index and throw away most of the work. What
> we should do of course is to improve the background refreshing task to
> batch stuff together and reduce the amount of wasted work.

Unlike my criticism of scanning hell, which is vitriolic, this is a
minor inconvenience. I'm not sure why you can't simply "git status" and
reset inside nb when clean, but you know best.

I'm just very, very grateful you built it. Thanks.