> So I really prefer not to. But you can take it up with Junio if you think > it can be a big deal. I began writing a patch but I abandoned it. I don't have much experience with the code base and I'd almost certainly miss a bunch of corner cases. Your patch seems to be the easiest way to go. I'm not motivated to push pre-emptive smudging, even if it might be more efficient. After all, how often does this race condition come up? But I have a per-file flagged version of the index for personal use, and it's good to know that it's a valid strategy. > Historically, we *never* did it. In fact, it was a big deal. These days we > do it opportunistically for "git diff" if we can, but making sure that it > all still works for a read-only access (think gitweb etc - the reader is > *not* necessarily the owner of the archive at all!) I hadn't thought about this case. This is intriguing: why does gitweb need access to the index? I thought the index was only to make operations fast for users intending to make changes to the repo. Why can't servers run stripped-down versions of git that don't bother with an index? -Ben -- 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
