On 2/10/07, Nicolas Pitre <nico@xxxxxxx> wrote:
On Sat, 10 Feb 2007, Junio C Hamano wrote: > (0) Do nothing. > > (1) We keep the current "git-status [-v] [-a] [[-i|-o] <paths...>]" > command line and do the necessary index manipulation > in-core without writing it out (see git-commit.sh for > details of what it involves). > > (2) We drop the support for any command line parameter from > "git-status", apply my two patches for Marco to > "git-runstatus", and rename "git-runstatus" to > "git-status". > > If I have to pick between the two, I would probably pick (2). > While (1) would essentially mean doing "git-commit" entirely > in-core without writing the index out until we really make the > commit, which is a good thing in itself in the longer term, it > is out of the question this late in the game for 1.5.0. And don't get me wrong. I think that for 1.5.0 you should really do (0).
I agree on doing (0) for 1.5.0 and the following Linus lines make me wonder if is better doing (0) also after 1.5.0
So the fact is, "git status" _needs_ to refresh the index. Because if it doesn't, you'll see every file that doesn't match the index as "dirty", and that is not just a "technical issue". And yes, doing an "internal" refresh, like Junio's patch does, hides the issue, but it hides it BY MAKING THE OPTIMIZATION POINTLESS! I suspect Marco is testing some reasonably small git archive. With something like git itself, with less than a thousand files (and most of them fairly small, so rehashing them all is quick), the optimization may _feel_ like just a small technical detail.
If current 'git runstatus' on a NTFS directory, Linux side, show as dirty _all_ the repo files, then in case of big repos, as Linus pointed out, a possible future 'git runstatus --refresh' will be terribly slow because must filter out as false positives _all_ the repo files. And worst, have to do it *any time* it is run. So perhaps the two patches of Junio _seems_ to work to me just because repo is small, is qgit4 indeed, but on a Linux tree would be veeery slow, so slow that probably is better to avoid completely and report quickly to user an empty set, being a corner case user will understand ;-) Marco P.S: I know I'm looking for flames but, if git-status HAVE to write the index and if 'status', as Nicolas points out, is a word that suggest a read only function, why don't change the name of the command.....'git sync-index' as example. - 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