Hi, 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. > 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. BTW I was a little concerned that the locking would fail in a read-only setup, and that git would die(), but that has been taken care of, so I have no objections left. Thanks, Junio. Ciao, Dscho - 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
