Git status indicators on Buffers tab

[curtiswren]

The little red dot to the left of the filename in the buffers tab doesn’t go away when you commit the change from the command line. It does if you commit from within slickedit. Not sure how to even get it to refresh other than restarting slickedit.

[Dan]

I need to clarify exactly where you are talking about.  Do you mean the Open tool window, or the File Tabs tool window?

[curtiswren]

The Buffers tab on the File “Tool Window”

[Dan]

It seems like it is not fetching these in the background.  Save will update them.  I will look into this.

[Dan]

This will be fixed for Beta 3.

[curtiswren]

Still seeing this issue on beta 3.

Thanks

[Dan]

I'm sorry for the inconvenience. Let me double check things.

[Dan]

I can verify that this is still an issue. I must have accidentally saved the file before.

[Dan]

Are your files in a workspace?

If so, what is the layout like?

You are seeing this issue on Linux, correct?

[curtiswren]

Some of the files are in the workspace. I typically just put my library header files in the workspace using *.h in the header directories.
Yes, this is on Linux.

Thanks

[Dan]

Do you see this problem with files that aren't in the workspace? That was how I was able to reproduce it.

[curtiswren]

I’m seeing it both with files in the workspace and not in the workspace

[Clark]

Fixed in beta 4. Please download beta 4 and give it a try.

[curtiswren]

Status is updating when committing from outside slickedit. I also tried testing with a restore, and that did not update. Still needed to re-save the file or restart slickedit to get that to update.

Minor issue on the help for Version Control Providers>Git>Get updates from git every (seconds). Help says this is in minutes.

In my other post about the spill file error, you mentioned to turn this off. Do you think this will potentially fix the spill file issue too?

Thanks

[Clark]

I don't know what you mean by "I also tried testing with a restore, and that did not update". What did you do here?

Thanks for catching the help file issue.

I don't think this feature is causing the spill file I/O issue but I can't explain why two people on Linux are getting it and I'm not. I've been using v28 for a very long time. I'm trying to run a release build (I usually run a debug build), keeping this feature on, and setting the spill file size to the smallest value possible (way smaller than the dialog let's you set it).