Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Fri, 31 Aug 2007, Jeff King wrote: > >> On Fri, Aug 31, 2007 at 01:13:42PM -0700, Junio C Hamano wrote: >> >> > If you set diff.autorefreshindex configuration variable, it >> > squelches the empty "diff --git" output, and at the end of the >> > command, it automatically runs "update-index --refresh" without >> > even bothering the user. In other words, with the configuration >> > variable set, people who do not care about the cache-dirtyness >> > do not even have to see the warning. >> >> Nice. This is much more sane behavior, IMHO, and I think it should make >> everyone happy. > > I could even imagine that this will eventually become the standard > behaviour. > >> > Same here. This patch saw only very light testing, but I >> > personally think is a sane thing to do before 1.5.3 final. >> >> Passes my light testing as well, but I have a feeling we just tested the >> same things...;) >> >> One question on the implementation (and remember that I am somewhat >> ignorant of the structure of this part of the code, so the answer may be >> "it's too ugly"): is there a good reason to refresh _after_ the diff? > > We do not need to do it always. After the diff, we know if the > index needs refreshing. Before, we don't. Hm. At the moment where it is first noticed, it should be still possible to start a refresh. Is there a particular gain to be expected? One thing I could think of is that when using a pager, the diff might often die of SIGPIPE before being able to refresh. >> It seems like when we are looking through the working tree and >> index the first time, we notice that the stat information doesn't >> match; why can't we update it then? That would save an extra >> working tree traversal. > > But that would be intrusive in the diff machinery IMHO. It should > stay as read-only as possible. Hm. Not sure where the gain is in that, if a refresh is done, anyway. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
