The issue with autorefreshing the commit view seems to be that if you
ask it to refresh while it's still refreshing, it freaks out. Seems
like a good opportunity to introduce a queue. There are a few other
options that will help reduce the issue, but the only thing that will
eliminate it is to make sure calling reload a bunch of times can't
break stuff.
- we can increase the interval between refreshes
- we can try use gitignore to not refresh if only ignored files have
been modified (this one might be tricky, but would unnecessary reduce
reloads during builds, etc)
Seems like it might be safer to only enable it for the history view to
start, since there will likely be more engineering involved in getting
the commit view to be stable.
-dave
On Sep 14, 2009, at 11:07 AM, Pieter de Bie wrote:
Hey everyone,
I've been thinking about 0.8 for a bit, and I think we should try to
keep the
releases small, and make more releases in general. There's enough
stuff we
should still add to GitX, so it doesn't hurt to have a fast release
cycle.
For 0.8 I'd like to see the following things included:
* dg/fsevents: autorefresh the repository. I'm not sure who is still
working
on this, perhaps Johannes? I think we can include a version that at
least
refreshes the history view
* pb/index_refactor: this doesn't add any new functionality, but
gives us a
solid base to extend index functions on later on.
* pb/sidebar: I think it would be best to just include the sidebar
without any
special functionality. We can extend it in 0.9 or later.
* The welcome screen. Unfortunately, it seems like I have deleted
all the code
I created for this, so I'll have to recreate it. I'll try to work
on that
this week.
Is there anything I've missed? I don't want to put a hard deadline
on this yet,
but I think we should be able to get a first version ready by the end
of the month.
- Pieter
