{"thread":{"id":"6755","subject":"'git status' is not read-only fs friendly","startedAt":"2007-02-09T19:25:04Z","lastAt":"2007-02-11T23:24:24Z","messageCount":52,"participants":["Marco Costalba","Linus Torvalds","Junio C Hamano","Morten Welinder","Theodore Tso","Johannes Schindelin","Nicolas Pitre","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"34072","messageId":"e5bfff550702091125j202620cfqb2450a3ee69ed421@mail.gmail.com","threadId":"6755","inReplyTo":null,"subject":"'git status' is not read-only fs friendly","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-09T19:25:04Z","receivedAt":"2007-02-09T19:25:04Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"In a repository under a mounted Windows directory (ntfs) I get this error:\n\n$ git status\nfatal: unable to create '.git/index.lock': Read-only file system\n$\n\nIs this correct? there exist a workaround? I just need to know if\ncurrent working directory is clean and report back to qgit user, so\nread-only access would be ok for me.\n\nAll other commands commonly used to browse a repository seems to work\nwell, without pretending to write stuff.\n\nThanks\nMarco\n"},{"id":"34074","messageId":"Pine.LNX.4.64.0702091148060.8424@woody.linux-foundation.org","threadId":"6755","inReplyTo":"e5bfff550702091125j202620cfqb2450a3ee69ed421@mail.gmail.com","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-09T19:56:18Z","receivedAt":"2007-02-09T19:56:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 9 Feb 2007, Marco Costalba wrote:\n>\n> In a repository under a mounted Windows directory (ntfs) I get this error:\n> \n> $ git status\n> fatal: unable to create '.git/index.lock': Read-only file system\n> $\n> \n> Is this correct? there exist a workaround? I just need to know if\n> current working directory is clean and report back to qgit user, so\n> read-only access would be ok for me.\n\n\"git status\" is kind of strange. It's really technically the engine behind \nthe messages for \"git commit\": both in a very real technical sense (it's \n_literally_ the same script:\"git-commit.sh\" is not just \"git-commit\", but \nalso \"git-status\"), but also in a very real historical \"that is what the \ncode was written for\".\n\nAnd you wouldn't think that it really needs write access, and you'd be \nlargely correct, EXCEPT for the fact that git status actually does a \nrefresh of the index, to make sure that we don't claim that something is \ndirty just because somebody has touched the file.\n\nIOW, there's an implicit \"git update-index --refresh\" as part of \ncalculating the status, and that's the thing that wants to lock the index \nfile (and thus write to the filesystem).\n\n> All other commands commonly used to browse a repository seems to work\n> well, without pretending to write stuff.\n\n\"git status\" doesn't \"pretend\" to write stuff. It really does. \n\nYou *can* just use \"git-runstatus\" instead. That's the command that \nactually does all the heavy lifting. But you can see the difference by \ndoing this:\n\n\ttouch Makefile\n\tgit runstatus\n\nvs\n\n\ttouch Makefile\n\tgit status\n\nNotice how the \"runstatus\" one claims that Makefile is \"modified:\". That's \nexactly because it doesn't do the index refresh.\n\n\t\t\tLinus\n"},{"id":"34075","messageId":"e5bfff550702091219n4df5531ek6be2cd04f00be650@mail.gmail.com","threadId":"6755","inReplyTo":"Pine.LNX.4.64.0702091148060.8424@woody.linux-foundation.org","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-09T20:19:54Z","receivedAt":"2007-02-09T20:19:54Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/9/07, Linus Torvalds wrote:\n>\n>\n\n> And you wouldn't think that it really needs write access, and you'd be\n> largely correct, EXCEPT for the fact that git status actually does a\n> refresh of the index, to make sure that we don't claim that something is\n> dirty just because somebody has touched the file.\n>\n> IOW, there's an implicit \"git update-index --refresh\" as part of\n> calculating the status, and that's the thing that wants to lock the index\n> file (and thus write to the filesystem).\n>\n------ cut ------\n>\n> You *can* just use \"git-runstatus\" instead. That's the command that\n> actually does all the heavy lifting. But you can see the difference by\n> doing this:\n>\n> touch Makefile\n> git runstatus\n>\n> vs\n>\n> touch Makefile\n> git status\n>\n> Notice how the \"runstatus\" one claims that Makefile is \"modified:\". That's\n> exactly because it doesn't do the index refresh.\n>\nSorry, perhaps it is a silly question, but why git index should be\ndifferent after just touching a file?\n\nIOW is it not possible that \"git update-index --refresh\" exists\nwithout modifing the index, just because ther's nothing to modify?\n\nSo, finally, could be possible making \"git status\" taking the lock\nonly _after_ has checked there's something new to write to the index?\nSo to avoid write access in most cases ? (expecially with repo mounted\non a read-only fs)\n\nThanks\nMarco\n"},{"id":"34076","messageId":"7vr6szt71j.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"Pine.LNX.4.64.0702091148060.8424@woody.linux-foundation.org","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-09T20:22:48Z","receivedAt":"2007-02-09T20:22:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> \"git status\" doesn't \"pretend\" to write stuff. It really does. \n>\n> You *can* just use \"git-runstatus\" instead. That's the command that \n> actually does all the heavy lifting. But you can see the difference by \n> doing this:\n>\n> \ttouch Makefile\n> \tgit runstatus\n>\n> vs\n>\n> \ttouch Makefile\n> \tgit status\n>\n> Notice how the \"runstatus\" one claims that Makefile is \"modified:\". That's \n> exactly because it doesn't do the index refresh.\n\nRunning refresh internally in runstatus without writing the\nresult out _might_ be an option, but that would largely be\na hack to only help qgit.\n\nOther shapes of \"git status\", such as \"git status \"\nand \"git status -a\", still need to perform the same index\nmanipulation as \"git commit\" with the same parameters before\ncalling git-runstatus, and at that point the extra \"internal\nrefresh\" in runstatus is an unwelcome extra cycle.\n"},{"id":"34077","messageId":"7vk5yrt6t0.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"e5bfff550702091219n4df5531ek6be2cd04f00be650@mail.gmail.com","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-09T20:27:55Z","receivedAt":"2007-02-09T20:27:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> Sorry, perhaps it is a silly question, but why git index should be\n> different after just touching a file?\n\nIt uses the information from lstat(2) that is stored in the\nindex and taken from the filesystem -- if they are different\n(touch changes it as you know, but so does \"vi that-file\") they\nare reported as \"modified\".\n\n\tgit checkout -- Makefile\n git diff-files Makefile\n\ttouch Makefile\n\tgit diff-files Makefile\n\nThe 'refresh' operation is to update the lstat(2) information in\nthe index for paths whose contents actually match what is in the\nindex (and it does not do anything else -- most notably paths\nwhose contents are different between the working tree and the\nindex are left as-is).\n"},{"id":"34078","messageId":"118833cc0702091229qfa0a3bcyae40b5e7ff70262b@mail.gmail.com","threadId":"6755","inReplyTo":"7vr6szt71j.fsf@assigned-by-dhcp.cox.net","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Morten Welinder","fromEmail":"mwelinder@gmail.com","sentAt":"2007-02-09T20:29:16Z","receivedAt":"2007-02-09T20:29:16Z","isPatch":false,"sender":{"key":"mwelinder@gmail.com","avatar":null},"body":"> Running refresh internally in runstatus without writing the\n> result out _might_ be an option, but that would largely be\n> a hack to only help qgit.\n\nI might be overlooking something, but couldn't that updated index be\nsaved elsewhere? And subcommands be pointed at that, of course.\n\nMorten\n"},{"id":"34079","messageId":"e5bfff550702091235x74e44362gad5b9b6076a5ea53@mail.gmail.com","threadId":"6755","inReplyTo":"7vr6szt71j.fsf@assigned-by-dhcp.cox.net","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-09T20:35:17Z","receivedAt":"2007-02-09T20:35:17Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/9/07, Junio C Hamano wrote:\n> Linus Torvalds writes:\n>\n> > \"git status\" doesn't \"pretend\" to write stuff. It really does.\n> >\n> > You *can* just use \"git-runstatus\" instead. That's the command that\n> > actually does all the heavy lifting. But you can see the difference by\n> > doing this:\n> >\n> > touch Makefile\n> > git runstatus\n> >\n> > vs\n> >\n> > touch Makefile\n> > git status\n> >\n> > Notice how the \"runstatus\" one claims that Makefile is \"modified:\". That's\n> > exactly because it doesn't do the index refresh.\n>\n> Running refresh internally in runstatus without writing the\n> result out _might_ be an option, but that would largely be\n> a hack to only help qgit.\n>\n\nYes, I agree.\n\nIf I modify qgit in running 'git runstatus' as a fallback in case 'git\nstatus' exits with an error (without checking what kind of error\nexactly) could be an acceptable path or could hide subtle\nside-effects? I have no the knowledge to answer this by hand.\n\nThanks\nMarco\n"},{"id":"34080","messageId":"Pine.LNX.4.64.0702091253120.8424@woody.linux-foundation.org","threadId":"6755","inReplyTo":"e5bfff550702091235x74e44362gad5b9b6076a5ea53@mail.gmail.com","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-09T20:59:22Z","receivedAt":"2007-02-09T20:59:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 9 Feb 2007, Marco Costalba wrote:\n> \n> If I modify qgit in running 'git runstatus' as a fallback in case 'git\n> status' exits with an error (without checking what kind of error\n> exactly) could be an acceptable path or could hide subtle\n> side-effects? I have no the knowledge to answer this by hand.\n\nIt's probably better for you to just\n\n - run \"git update-index --refresh\" and don't care about the exit value\n - run \"git runstatus\" unconditionally\n\nwhich should basically get you something working.\n\nHOWEVER, it's also quite possible that \"git-commit.sh\" should just do this \non its own. If the update-index fails, we really only care if we literally \nuse the index later to *write* something, ie the commit case. For just \n\"git status\", maybe we should just silently ignore the error..\n\n\t\tLinus\n"},{"id":"34082","messageId":"20070209232750.GE10484@thunk.org","threadId":"6755","inReplyTo":"118833cc0702091229qfa0a3bcyae40b5e7ff70262b@mail.gmail.com","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-02-09T23:27:51Z","receivedAt":"2007-02-09T23:27:51Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Feb 09, 2007 at 03:29:16PM -0500, Morten Welinder wrote:\n> >Running refresh internally in runstatus without writing the\n> >result out _might_ be an option, but that would largely be\n> >a hack to only help qgit.\n> \n> I might be overlooking something, but couldn't that updated index be\n> saved elsewhere? And subcommands be pointed at that, of course.\n\nYou should be able to set the GIT_INDEX_FILE environtment variable to\npoint the index somewhere else than $GIT_DIR/index, so it's not\nlocated on a read-only filesystem. See the git(7) man page.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"34083","messageId":"7vmz3mq394.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"Pine.LNX.4.64.0702091253120.8424@woody.linux-foundation.org","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-10T00:12:55Z","receivedAt":"2007-02-10T00:12:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 9 Feb 2007, Marco Costalba wrote:\n>> \n>> If I modify qgit in running 'git runstatus' as a fallback in case 'git\n>> status' exits with an error (without checking what kind of error\n>> exactly) could be an acceptable path or could hide subtle\n>> side-effects? I have no the knowledge to answer this by hand.\n>\n> It's probably better for you to just\n>\n> - run \"git update-index --refresh\" and don't care about the exit value\n> - run \"git runstatus\" unconditionally\n>\n> which should basically get you something working.\n\nWe could do \"git runstatus --refresh\", which only updates the\nindex in-core.\n\nThe patch does two things.\n\n - it changes the calling convention of run_diff_files() and\n run_diff_index(); earlier, they read the index on their own,\n but now we expect the caller to have populated the index by\n calling read_cache().\n\n - it adds --refresh flag to git-runstatus, and before\n git-runstatus calls read_cache() to satisfy the updated\n calling convention of run_diff_files() and run_diff_index(),\n it refreshes the in-core copy of index.\n\n---\ndiff --git a/builtin-diff-files.c b/builtin-diff-files.c\nindex 5d4a5c5..3ee2605 100644\n--- a/builtin-diff-files.c\n+++ b/builtin-diff-files.c\n@@ -47,5 +47,9 @@ int cmd_diff_files(int argc, const char **argv, const char *prefix)\n \tif (rev.pending.nr ||\n \t rev.min_age != -1 || rev.max_age != -1)\n \t\tusage(diff_files_usage);\n+\tif (read_cache() < 0) {\n+\t\tperror(\"read_cache\");\n+\t\treturn -1;\n+\t}\n \treturn run_diff_files(&rev, silent);\n }\ndiff --git a/builtin-diff-index.c b/builtin-diff-index.c\nindex 95a3db1..083599d 100644\n--- a/builtin-diff-index.c\n+++ b/builtin-diff-index.c\n@@ -38,5 +38,9 @@ int cmd_diff_index(int argc, const char **argv, const char *prefix)\n \tif (rev.pending.nr != 1 ||\n \t rev.max_count != -1 || rev.min_age != -1 || rev.max_age != -1)\n \t\tusage(diff_cache_usage);\n+\tif (read_cache() < 0) {\n+\t\tperror(\"read_cache\");\n+\t\treturn -1;\n+\t}\n \treturn run_diff_index(&rev, cached);\n }\ndiff --git a/builtin-diff.c b/builtin-diff.c\nindex a659020..12d11f0 100644\n--- a/builtin-diff.c\n+++ b/builtin-diff.c\n@@ -56,6 +56,10 @@ static int builtin_diff_files(struct rev_info *revs,\n \tif (revs->max_count < 0 &&\n \t (revs->diffopt.output_format & DIFF_FORMAT_PATCH))\n \t\trevs->combine_merges = revs->dense_combined_merges = 1;\n+\tif (read_cache() < 0) {\n+\t\tperror(\"read_cache\");\n+\t\treturn -1;\n+\t}\n \treturn run_diff_files(revs, silent);\n }\n \n@@ -151,6 +155,10 @@ static int builtin_diff_index(struct rev_info *revs,\n \t revs->max_count != -1 || revs->min_age != -1 ||\n \t revs->max_age != -1)\n \t\tusage(builtin_diff_usage);\n+\tif (read_cache() < 0) {\n+\t\tperror(\"read_cache\");\n+\t\treturn -1;\n+\t}\n \treturn run_diff_index(revs, cached);\n }\n \ndiff --git a/builtin-runstatus.c b/builtin-runstatus.c\nindex 4b489b1..df66742 100644\n--- a/builtin-runstatus.c\n+++ b/builtin-runstatus.c\n@@ -4,7 +4,7 @@\n extern int wt_status_use_color;\n \n static const char runstatus_usage[] =\n-\"git-runstatus [--color|--nocolor] [--amend] [--verbose] [--untracked]\";\n+\"git-runstatus [--color|--nocolor] [--refresh] [--amend] [--verbose] [--untracked]\";\n \n int cmd_runstatus(int argc, const char **argv, const char *prefix)\n {\n@@ -17,6 +17,8 @@ int cmd_runstatus(int argc, const char **argv, const char *prefix)\n \tfor (i = 1; i < argc; i++) {\n \t\tif (!strcmp(argv[i], \"--color\"))\n \t\t\twt_status_use_color = 1;\n+\t\telse if (!strcmp(argv[i], \"--refresh\"))\n+\t\t\ts.refresh = 1;\n \t\telse if (!strcmp(argv[i], \"--nocolor\"))\n \t\t\twt_status_use_color = 0;\n \t\telse if (!strcmp(argv[i], \"--amend\")) {\ndiff --git a/diff-lib.c b/diff-lib.c\nindex 91cd877..278ba79 100644\n--- a/diff-lib.c\n+++ b/diff-lib.c\n@@ -20,11 +20,7 @@ int run_diff_files(struct rev_info *revs, int silent_on_removed)\n \n \tif (diff_unmerged_stage < 0)\n \t\tdiff_unmerged_stage = 2;\n-\tentries = read_cache();\n-\tif (entries < 0) {\n-\t\tperror(\"read_cache\");\n-\t\treturn -1;\n-\t}\n+\tentries = active_nr;\n \tfor (i = 0; i < entries; i++) {\n \t\tstruct stat st;\n \t\tunsigned int oldmode, newmode;\n@@ -354,10 +350,6 @@ int run_diff_index(struct rev_info *revs, int cached)\n \tif (!revs->ignore_merges)\n \t\tmatch_missing = 1;\n \n-\tif (read_cache() < 0) {\n-\t\tperror(\"read_cache\");\n-\t\treturn -1;\n-\t}\n \tmark_merge_entries();\n \n \tent = revs->pending.objects[0].item;\ndiff --git a/wt-status.c b/wt-status.c\nindex 5567868..58186d6 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -47,17 +47,10 @@ void wt_status_prepare(struct wt_status *s)\n \tunsigned char sha1[20];\n \tconst char *head;\n \n+\tmemset(s, 0, sizeof(*s));\n \thead = resolve_ref(\"HEAD\", sha1, 0, NULL);\n \ts->branch = head ? xstrdup(head) : NULL;\n-\n \ts->reference = \"HEAD\";\n-\ts->amend = 0;\n-\ts->verbose = 0;\n-\ts->untracked = 0;\n-\n-\ts->commitable = 0;\n-\ts->workdir_dirty = 0;\n-\ts->workdir_untracked = 0;\n }\n \n static void wt_status_print_cached_header(const char *reference)\n@@ -198,12 +191,22 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,\n \t\twt_status_print_trailer();\n }\n \n+static void wt_read_cache(struct wt_status *s)\n+{\n+\tdiscard_cache();\n+\tread_cache();\n+\tif (s->refresh)\n+\t\trefresh_cache(0);\n+}\n+\n void wt_status_print_initial(struct wt_status *s)\n {\n \tint i;\n \tchar buf[PATH_MAX];\n \n-\tread_cache();\n+\twt_read_cache(s);\n+\tif (s->refresh)\n+\t\trefresh_cache(REFRESH_QUIET);\n \tif (active_nr) {\n \t\ts->commitable = 1;\n \t\twt_status_print_cached_header(NULL);\n@@ -227,6 +230,7 @@ static void wt_status_print_updated(struct wt_status *s)\n \trev.diffopt.format_callback = wt_status_print_updated_cb;\n \trev.diffopt.format_callback_data = s;\n \trev.diffopt.detect_rename = 1;\n+\twt_read_cache(s);\n \trun_diff_index(&rev, 1);\n }\n \n@@ -238,6 +242,7 @@ static void wt_status_print_changed(struct wt_status *s)\n \trev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;\n \trev.diffopt.format_callback = wt_status_print_changed_cb;\n \trev.diffopt.format_callback_data = s;\n+\twt_read_cache(s);\n \trun_diff_files(&rev, 0);\n }\n \n@@ -294,6 +299,7 @@ static void wt_status_print_verbose(struct wt_status *s)\n \tsetup_revisions(0, NULL, &rev, s->reference);\n \trev.diffopt.output_format |= DIFF_FORMAT_PATCH;\n \trev.diffopt.detect_rename = 1;\n+\twt_read_cache(s);\n \trun_diff_index(&rev, 1);\n }\n \n@@ -323,7 +329,6 @@ void wt_status_print(struct wt_status *s)\n \t}\n \telse {\n \t\twt_status_print_updated(s);\n-\t\tdiscard_cache();\n \t}\n \n \twt_status_print_changed(s);\ndiff --git a/wt-status.h b/wt-status.h\nindex cfea4ae..680a0ca 100644\n--- a/wt-status.h\n+++ b/wt-status.h\n@@ -15,6 +15,7 @@ struct wt_status {\n \tint verbose;\n \tint amend;\n \tint untracked;\n+\tint refresh;\n \t/* These are computed during processing of the individual sections */\n \tint commitable;\n \tint workdir_dirty;\n"},{"id":"34085","messageId":"7vejoyq330.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"7vmz3mq394.fsf@assigned-by-dhcp.cox.net","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-10T00:16:35Z","receivedAt":"2007-02-10T00:16:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> We could do \"git runstatus --refresh\", which only updates the\n> index in-core.\n>\n> The patch does two things.\n\nAh, crap. Sorry for a wip.\n"},{"id":"34086","messageId":"7vy7n6ohc3.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"7vejoyq330.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH 1/2] run_diff_{files,index}(): update calling convention.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-10T02:51:40Z","receivedAt":"2007-02-10T02:51:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"They used to open and read index themselves, but they now expect\ntheir callers to do so.\n\nSigned-off-by: Junio C Hamano \n---\n * This is preparatoin for the next one...\n\n builtin-diff-files.c | 4 ++++\n builtin-diff-index.c | 4 ++++\n builtin-diff.c | 8 ++++++++\n diff-lib.c | 10 +---------\n wt-status.c | 12 ++++++++++--\n 5 files changed, 27 insertions(+), 11 deletions(-)\n\ndiff --git a/builtin-diff-files.c b/builtin-diff-files.c\nindex 5d4a5c5..3ee2605 100644\n--- a/builtin-diff-files.c\n+++ b/builtin-diff-files.c\n@@ -47,5 +47,9 @@ int cmd_diff_files(int argc, const char **argv, const char *prefix)\n \tif (rev.pending.nr ||\n \t rev.min_age != -1 || rev.max_age != -1)\n \t\tusage(diff_files_usage);\n+\tif (read_cache() < 0) {\n+\t\tperror(\"read_cache\");\n+\t\treturn -1;\n+\t}\n \treturn run_diff_files(&rev, silent);\n }\ndiff --git a/builtin-diff-index.c b/builtin-diff-index.c\nindex 95a3db1..083599d 100644\n--- a/builtin-diff-index.c\n+++ b/builtin-diff-index.c\n@@ -38,5 +38,9 @@ int cmd_diff_index(int argc, const char **argv, const char *prefix)\n \tif (rev.pending.nr != 1 ||\n \t rev.max_count != -1 || rev.min_age != -1 || rev.max_age != -1)\n \t\tusage(diff_cache_usage);\n+\tif (read_cache() < 0) {\n+\t\tperror(\"read_cache\");\n+\t\treturn -1;\n+\t}\n \treturn run_diff_index(&rev, cached);\n }\ndiff --git a/builtin-diff.c b/builtin-diff.c\nindex a659020..12d11f0 100644\n--- a/builtin-diff.c\n+++ b/builtin-diff.c\n@@ -56,6 +56,10 @@ static int builtin_diff_files(struct rev_info *revs,\n \tif (revs->max_count < 0 &&\n \t (revs->diffopt.output_format & DIFF_FORMAT_PATCH))\n \t\trevs->combine_merges = revs->dense_combined_merges = 1;\n+\tif (read_cache() < 0) {\n+\t\tperror(\"read_cache\");\n+\t\treturn -1;\n+\t}\n \treturn run_diff_files(revs, silent);\n }\n \n@@ -151,6 +155,10 @@ static int builtin_diff_index(struct rev_info *revs,\n \t revs->max_count != -1 || revs->min_age != -1 ||\n \t revs->max_age != -1)\n \t\tusage(builtin_diff_usage);\n+\tif (read_cache() < 0) {\n+\t\tperror(\"read_cache\");\n+\t\treturn -1;\n+\t}\n \treturn run_diff_index(revs, cached);\n }\n \ndiff --git a/diff-lib.c b/diff-lib.c\nindex 91cd877..278ba79 100644\n--- a/diff-lib.c\n+++ b/diff-lib.c\n@@ -20,11 +20,7 @@ int run_diff_files(struct rev_info *revs, int silent_on_removed)\n \n \tif (diff_unmerged_stage < 0)\n \t\tdiff_unmerged_stage = 2;\n-\tentries = read_cache();\n-\tif (entries < 0) {\n-\t\tperror(\"read_cache\");\n-\t\treturn -1;\n-\t}\n+\tentries = active_nr;\n \tfor (i = 0; i < entries; i++) {\n \t\tstruct stat st;\n \t\tunsigned int oldmode, newmode;\n@@ -354,10 +350,6 @@ int run_diff_index(struct rev_info *revs, int cached)\n \tif (!revs->ignore_merges)\n \t\tmatch_missing = 1;\n \n-\tif (read_cache() < 0) {\n-\t\tperror(\"read_cache\");\n-\t\treturn -1;\n-\t}\n \tmark_merge_entries();\n \n \tent = revs->pending.objects[0].item;\ndiff --git a/wt-status.c b/wt-status.c\nindex 2879c3d..e346511 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -191,12 +191,18 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,\n \t\twt_status_print_trailer();\n }\n \n+static void wt_read_cache(struct wt_status *s)\n+{\n+\tdiscard_cache();\n+\tread_cache();\n+}\n+\n void wt_status_print_initial(struct wt_status *s)\n {\n \tint i;\n \tchar buf[PATH_MAX];\n \n-\tread_cache();\n+\twt_read_cache(s);\n \tif (active_nr) {\n \t\ts->commitable = 1;\n \t\twt_status_print_cached_header(NULL);\n@@ -220,6 +226,7 @@ static void wt_status_print_updated(struct wt_status *s)\n \trev.diffopt.format_callback = wt_status_print_updated_cb;\n \trev.diffopt.format_callback_data = s;\n \trev.diffopt.detect_rename = 1;\n+\twt_read_cache(s);\n \trun_diff_index(&rev, 1);\n }\n \n@@ -231,6 +238,7 @@ static void wt_status_print_changed(struct wt_status *s)\n \trev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;\n \trev.diffopt.format_callback = wt_status_print_changed_cb;\n \trev.diffopt.format_callback_data = s;\n+\twt_read_cache(s);\n \trun_diff_files(&rev, 0);\n }\n \n@@ -287,6 +295,7 @@ static void wt_status_print_verbose(struct wt_status *s)\n \tsetup_revisions(0, NULL, &rev, s->reference);\n \trev.diffopt.output_format |= DIFF_FORMAT_PATCH;\n \trev.diffopt.detect_rename = 1;\n+\twt_read_cache(s);\n \trun_diff_index(&rev, 1);\n }\n \n@@ -316,7 +325,6 @@ void wt_status_print(struct wt_status *s)\n \t}\n \telse {\n \t\twt_status_print_updated(s);\n-\t\tdiscard_cache();\n \t}\n \n \twt_status_print_changed(s);\n-- \n1.5.0.rc4.26.gcc46\n"},{"id":"34087","messageId":"7vr6syohbo.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"7vejoyq330.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH 2/2] git-runstatus --refresh","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-10T02:51:55Z","receivedAt":"2007-02-10T02:51:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This teaches git-runstatus a new option --refresh to refresh the\nindex in-core.\n\nSigned-off-by: Junio C Hamano \n---\n * If a cache has 20k+ paths, this could be rather expensive\n because git-status already have refreshed the entries for us,\n so I am reluctant to make this the default, but obviously\n then qgit needs to know if it has runstatus that knows about\n this option.\n\n builtin-runstatus.c | 4 +++-\n wt-status.c | 2 ++\n wt-status.h | 1 +\n 3 files changed, 6 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-runstatus.c b/builtin-runstatus.c\nindex 4b489b1..df66742 100644\n--- a/builtin-runstatus.c\n+++ b/builtin-runstatus.c\n@@ -4,7 +4,7 @@\n extern int wt_status_use_color;\n \n static const char runstatus_usage[] =\n-\"git-runstatus [--color|--nocolor] [--amend] [--verbose] [--untracked]\";\n+\"git-runstatus [--color|--nocolor] [--refresh] [--amend] [--verbose] [--untracked]\";\n \n int cmd_runstatus(int argc, const char **argv, const char *prefix)\n {\n@@ -17,6 +17,8 @@ int cmd_runstatus(int argc, const char **argv, const char *prefix)\n \tfor (i = 1; i < argc; i++) {\n \t\tif (!strcmp(argv[i], \"--color\"))\n \t\t\twt_status_use_color = 1;\n+\t\telse if (!strcmp(argv[i], \"--refresh\"))\n+\t\t\ts.refresh = 1;\n \t\telse if (!strcmp(argv[i], \"--nocolor\"))\n \t\t\twt_status_use_color = 0;\n \t\telse if (!strcmp(argv[i], \"--amend\")) {\ndiff --git a/wt-status.c b/wt-status.c\nindex e346511..27c228b 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -195,6 +195,8 @@ static void wt_read_cache(struct wt_status *s)\n {\n \tdiscard_cache();\n \tread_cache();\n+\tif (s->refresh)\n+\t\trefresh_cache(REFRESH_QUIET);\n }\n \n void wt_status_print_initial(struct wt_status *s)\ndiff --git a/wt-status.h b/wt-status.h\nindex cfea4ae..680a0ca 100644\n--- a/wt-status.h\n+++ b/wt-status.h\n@@ -15,6 +15,7 @@ struct wt_status {\n \tint verbose;\n \tint amend;\n \tint untracked;\n+\tint refresh;\n \t/* These are computed during processing of the individual sections */\n \tint commitable;\n \tint workdir_dirty;\n-- \n1.5.0.rc4.26.gcc46\n"},{"id":"34089","messageId":"e5bfff550702100002y3929c50mfb99b8da44c9c82b@mail.gmail.com","threadId":"6755","inReplyTo":"7vy7n6ohc3.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/2] run_diff_{files,index}(): update calling convention.","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-10T08:02:15Z","receivedAt":"2007-02-10T08:02:15Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/10/07, Junio C Hamano wrote:\n> They used to open and read index themselves, but they now expect\n> their callers to do so.\n>\n> Signed-off-by: Junio C Hamano \n> ---\n\nThanks this works for me, while the other workaround seems to have issues:\n\nbash-3.1$ git status\nfatal: unable to create '.git/index.lock': Read-only file system\nbash-3.1$ git update-index --refresh\nfatal: unable to create '.git/index.lock': Read-only file system\nbash-3.1$ git runstatus\n# On branch master\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n#\n# modified: .gitignore\n# modified: README\n# modified: exception_manager.txt\n\n ------ cut -------\n\n# src/object_script.qgit.Release\n# src/object_script.qgit_bin.Debug\n# src/object_script.qgit_bin.Release\n# start_qgit.bat\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\n\nbash-3.1$ git-runstatus --refresh\n# On branch master\n# Untracked files:\n# (use \"git add ...\" to include in what will be committed)\n#\n# AAA_convert.xls.lnk\n# Cygwin.lnk\n# Qt 4.2.2 Command Prompt.lnk\n# bld.bat\n# cmd.txt\n# explore2fs.exe.lnk\n# qgit.lnk\n# src/object_script.qgit.Debug\n# src/object_script.qgit.Release\n# src/object_script.qgit_bin.Debug\n# src/object_script.qgit_bin.Release\n# start_qgit.bat\nnothing added to commit but untracked files present (use \"git add\" to track)\nbash-3.1$\n\nRunning 'git runstatus' alone shows _all_ the repo files, although are\nnot modified and not touched. With 'git runstatus' --refresh'\neverything seems ok.\n\nPlease could you apply your patch before 1.5 so that I can update qgit\nand change prerequisite git version to 1.5.\n\nThanks\nMarco\n"},{"id":"34090","messageId":"7vps8imnis.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"e5bfff550702100002y3929c50mfb99b8da44c9c82b@mail.gmail.com","subject":"Re: [PATCH 1/2] run_diff_{files,index}(): update calling convention.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-10T08:20:59Z","receivedAt":"2007-02-10T08:20:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> Running 'git runstatus' alone shows _all_ the repo files, although are\n> not modified and not touched.\n\nThat does not sound right with or without my patch. Are you\ntalking about the 'git runstatus' with my patch is showing\npaths that are cache clean? If that is the case that means my\npatch is introudcing regression.\n"},{"id":"34091","messageId":"e5bfff550702100029h65d1fd3fke5496da0664642ee@mail.gmail.com","threadId":"6755","inReplyTo":"7vps8imnis.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/2] run_diff_{files,index}(): update calling convention.","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-10T08:29:52Z","receivedAt":"2007-02-10T08:29:52Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/10/07, Junio C Hamano wrote:\n> \"Marco Costalba\" writes:\n>\n> > Running 'git runstatus' alone shows _all_ the repo files, although are\n> > not modified and not touched.\n>\n> That does not sound right with or without my patch. Are you\n> talking about the 'git runstatus' with my patch is showing\n> paths that are cache clean? If that is the case that means my\n> patch is introudcing regression.\n>\n>\n'git runstatus' shows all the files also _before_ your patch has been\napplied (I have tested again now resetting HEAD so to remove your two\npatches).\n\nWhat is strange is that running 'git runstatus' on Linux on a repo\nunder a ntfs directory shows all the files, while running 'git status'\nunder windows under the same repo (so now we have write access) shows\nthings correctly.\n\nIt seems that perhaps lstat(2) info of a mounted ntfs directory is not\ncorrect?????? very very strange!\n"},{"id":"34092","messageId":"e5bfff550702100046m1c0b1931t11ed0cf95853cda9@mail.gmail.com","threadId":"6755","inReplyTo":"e5bfff550702100029h65d1fd3fke5496da0664642ee@mail.gmail.com","subject":"Re: [PATCH 1/2] run_diff_{files,index}(): update calling convention.","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-10T08:46:10Z","receivedAt":"2007-02-10T08:46:10Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/10/07, Marco Costalba wrote:\n> >\n> 'git runstatus' shows all the files also _before_ your patch has been\n> applied (I have tested again now resetting HEAD so to remove your two\n> patches).\n>\n\nThis is the complete log under Windows (git with Cygwin distribution,\nbut run _outside_ cygwin shell, directly in Windows cmd.exe shell).\n\nAnd _after_ under Linus, current git tree _without_ your last patches applied.\n\n*************** UNDER WINDOWS ***********************\n\nC:\\varie\\c\\qgit4>git status\n# Untracked files:\n# (use \"git add\" to add to commit)\n#\n#\tAAA_convert.xls.lnk\n#\tCygwin.lnk\n#\tQt 4.2.2 Command Prompt.lnk\n#\tbld.bat\n#\tcmd.txt\n#\texplore2fs.exe.lnk\n#\tlog.txt\n#\tqgit.lnk\n#\tsrc/object_script.qgit.Debug\n#\tsrc/object_script.qgit.Release\n#\tsrc/object_script.qgit_bin.Debug\n#\tsrc/object_script.qgit_bin.Release\n#\tstart_qgit.bat\nnothing to commit\n\nC:\\varie\\c\\qgit4>git runstatus\n# Untracked files:\n# (use \"git add\" to add to commit)\n#\n#\tAAA_convert.xls.lnk\n#\tCygwin.lnk\n#\tQt 4.2.2 Command Prompt.lnk\n#\tbld.bat\n#\tcmd.txt\n#\texplore2fs.exe.lnk\n#\tlog.txt\n#\tqgit.lnk\n#\tsrc/object_script.qgit.Debug\n#\tsrc/object_script.qgit.Release\n#\tsrc/object_script.qgit_bin.Debug\n#\tsrc/object_script.qgit_bin.Release\n#\tstart_qgit.bat\nnothing to commit\n\n\n*************** UNDER LINUX **************************\n\nbash-3.1$ git status\nfatal: unable to create '.git/index.lock': Read-only file system\nbash-3.1$ git runstatus\n# On branch master\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n#\n# modified: .gitignore\n# modified: README\n# modified: exception_manager.txt\n# modified: qgit.pro\n# modified: src/annotate.cpp\n# modified: src/annotate.h\n# modified: src/cache.cpp\n# modified: src/cache.h\n# modified: src/commit.ui\n# modified: src/commitimpl.cpp\n\n------------- cut (all remaining files) -----------------------\n\n# modified: src/resources/source_h.png\n# modified: src/resources/source_java.png\n# modified: src/resources/source_pl.png\n# modified: src/resources/source_py.png\n# modified: src/resources/tab_remove.png\n# modified: src/resources/tar.png\n# modified: src/resources/txt.png\n# modified: src/resources/view_choose.png\n# modified: src/resources/view_top_bottom.png\n# modified: src/resources/view_tree.png\n# modified: src/resources/wizard.png\n# modified: src/revdesc.cpp\n# modified: src/revdesc.h\n# modified: src/revsview.cpp\n# modified: src/revsview.h\n# modified: src/revsview.ui\n# modified: src/settings.ui\n# modified: src/settingsimpl.cpp\n# modified: src/settingsimpl.h\n# modified: src/src.pro\n# modified: src/todo.txt\n# modified: src/treeview.cpp\n# modified: src/treeview.h\n#\n# Untracked files:\n# (use \"git add ...\" to include in what will be committed)\n#\n# AAA_convert.xls.lnk\n# Cygwin.lnk\n# Qt 4.2.2 Command Prompt.lnk\n# bld.bat\n# cmd.txt\n# explore2fs.exe.lnk\n# log.txt\n# qgit.lnk\n# src/object_script.qgit.Debug\n# src/object_script.qgit.Release\n# src/object_script.qgit_bin.Debug\n# src/object_script.qgit_bin.Release\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\nbash-3.1$\n"},{"id":"34096","messageId":"7vhctumh1m.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"e5bfff550702100046m1c0b1931t11ed0cf95853cda9@mail.gmail.com","subject":"Re: [PATCH 1/2] run_diff_{files,index}(): update calling convention.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-10T10:40:53Z","receivedAt":"2007-02-10T10:40:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I suspect that you are dual booting and browsing a git\nrepository that is on a read-only mounted NTFS filesystem from\nthe Linux side, and the index was created on Cygwin git?\n\nI (perhaps luckily) am fairly ignorant on the way things done in\nWindows environment. For one thing, I do not know if NTFS has\nnotion of i-number, file owner uid, and other information that\nare used in the index (not that I want to know).\n\nIf NTFS does not support the information returned by lstat(2)\nfully on disk, I would imagine Cygwin and NTFS filesystem driver\nin the Linux kernel need to fake some fields that NTFS does not\nnatively store, and if the value faked by Cygwin and NTFS driver\nin the Linux kernel disagree, then it is not at all surprising\nto see if an unmodified path shows up as cache-dirty.\n"},{"id":"34097","messageId":"e5bfff550702100325v5ce9ba1fx4b9b7adcc5040948@mail.gmail.com","threadId":"6755","inReplyTo":"7vhctumh1m.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/2] run_diff_{files,index}(): update calling convention.","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-10T11:25:54Z","receivedAt":"2007-02-10T11:25:54Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/10/07, Junio C Hamano wrote:\n> I suspect that you are dual booting and browsing a git\n> repository that is on a read-only mounted NTFS filesystem from\n> the Linux side, and the index was created on Cygwin git?\n>\n\nYes. That's it.\n\n> I (perhaps luckily) am fairly ignorant on the way things done in\n> Windows environment. For one thing, I do not know if NTFS has\n> notion of i-number, file owner uid, and other information that\n> are used in the index (not that I want to know).\n>\n> If NTFS does not support the information returned by lstat(2)\n> fully on disk, I would imagine Cygwin and NTFS filesystem driver\n> in the Linux kernel need to fake some fields that NTFS does not\n> natively store, and if the value faked by Cygwin and NTFS driver\n> in the Linux kernel disagree, then it is not at all surprising\n> to see if an unmodified path shows up as cache-dirty.\n>\n\nSo in this case your patch that introduce '--refresh' option in 'git\nrunstatus' is not just a shortcut for 'git update-index' + 'git\nrunstatus' but adds some real value.\n\nOne more reason for asking you to add it before 1.5 release ;-)\n"},{"id":"34098","messageId":"Pine.LNX.4.63.0702101517360.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6755","inReplyTo":"e5bfff550702091125j202620cfqb2450a3ee69ed421@mail.gmail.com","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-10T14:19:59Z","receivedAt":"2007-02-10T14:19:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 9 Feb 2007, Marco Costalba wrote:\n\n> I just need to know if current working directory is clean and report \n> back to qgit user, so read-only access would be ok for me.\n\nSo, why don't you just do a\n\n\tgit diff --name-only HEAD\n\nand check for an empty output???\n\nNo need for a patch to Git (so late in the -rc phase), or backwards \nincompatibility...\n\nCiao,\nDscho\n"},{"id":"34100","messageId":"e5bfff550702100631w1b6243e7i44039ceaa8d3fe93@mail.gmail.com","threadId":"6755","inReplyTo":"Pine.LNX.4.63.0702101517360.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-10T14:31:37Z","receivedAt":"2007-02-10T14:31:37Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/10/07, Johannes Schindelin wrote:\n> Hi,\n>\n> On Fri, 9 Feb 2007, Marco Costalba wrote:\n>\n> > I just need to know if current working directory is clean and report\n> > back to qgit user, so read-only access would be ok for me.\n>\n> So, why don't you just do a\n>\n> git diff --name-only HEAD\n>\n> and check for an empty output???\n>\n\nIt seems to have the same issues of 'git runstatus' in case of ntfs\nfilesystems, so I would prefer, eventually, use 'git runstatus' that\nat least gives me index status of the files.\n\n> No need for a patch to Git (so late in the -rc phase), or backwards\n> incompatibility...\n>\n\nWell, it's a _new_ option so I fail to see backwards incompatibility.\nPerhaps you are referring to qgit backward incompatibility, but in any\ncase a new version of qgit is due to fix a parsing bug that shows\nafter a modification of 'git rev-list' output occurred in git 1.5\ndevelopment.\n\n Marco\n"},{"id":"34104","messageId":"Pine.LNX.4.63.0702101536090.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6755","inReplyTo":"e5bfff550702100631w1b6243e7i44039ceaa8d3fe93@mail.gmail.com","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-10T14:41:22Z","receivedAt":"2007-02-10T14:41:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 10 Feb 2007, Marco Costalba wrote:\n\n> On 2/10/07, Johannes Schindelin wrote:\n> > On Fri, 9 Feb 2007, Marco Costalba wrote:\n> > \n> > > I just need to know if current working directory is clean and report\n> > > back to qgit user, so read-only access would be ok for me.\n> > \n> > So, why don't you just do a\n> > \n> > git diff --name-only HEAD\n> > \n> > and check for an empty output???\n> \n> It seems to have the same issues of 'git runstatus' in case of ntfs \n> filesystems, so I would prefer, eventually, use 'git runstatus' that at \n> least gives me index status of the files.\n\nWhich issues? That the lstat data are not equal on Cygwin and Linux? The \npatch does not help here. Maybe a patch to Linux' ntfs driver \nwould, but I fail to see how Git could possibly help here.\n\nIf git-diff is trying to write files, _that_ would be a bug.\n\nAs for your use of git-status: I think it is wrong. You said you want to \ncheck if the working directory is clean. Then just do that, and do not try \nto generate the message meant for editing the commit message.\n\n> > No need for a patch to Git (so late in the -rc phase), or backwards \n> > incompatibility...\n> \n> Well, it's a _new_ option so I fail to see backwards incompatibility.\n\nYou need a new version of _Git_ if you use that option.\n\nAnd if you can do without depending on a newer Git, it is _bad_ to do it \nnevertheless.\n\nCiao,\nDscho\n"},{"id":"34105","messageId":"e5bfff550702100648p6db5fc67vb5e4a04d40771922@mail.gmail.com","threadId":"6755","inReplyTo":"Pine.LNX.4.63.0702101536090.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-10T14:48:45Z","receivedAt":"2007-02-10T14:48:45Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/10/07, Johannes Schindelin wrote:\n> Hi,\n>\n> On Sat, 10 Feb 2007, Marco Costalba wrote:\n>\n> > On 2/10/07, Johannes Schindelin wrote:\n> > > On Fri, 9 Feb 2007, Marco Costalba wrote:\n> > >\n> > > > I just need to know if current working directory is clean and report\n> > > > back to qgit user, so read-only access would be ok for me.\n> > >\n> > > So, why don't you just do a\n> > >\n> > > git diff --name-only HEAD\n> > >\n> > > and check for an empty output???\n> >\n> > It seems to have the same issues of 'git runstatus' in case of ntfs\n> > filesystems, so I would prefer, eventually, use 'git runstatus' that at\n> > least gives me index status of the files.\n>\n> Which issues? That the lstat data are not equal on Cygwin and Linux? The\n> patch does not help here.\n\nWell, I tested the patch and indeed it helps a lot ;-)\n\nIt's correct that checking Linux lstat against cygwin one (stored in\nindex) gives different results, but it's now where the patch makes the\ndifference rechecking all the files (in memory) to see if are really\nchanged and discarding false positives created by lstat issues.\n\n> Maybe a patch to Linux' ntfs driver\n> would, but I fail to see how Git could possibly help here.\n\n>\n> You need a new version of _Git_ if you use that option.\n>\n\nThat's a true point. Altough if git 1.5 ships _without_ '--refresh'\noption in 'git runstatus' for a porcelain tool point of view it means\n*do forget* that option until next major release. There's no point in\nadding the feature one day after git 1.5 is out; qgit will not use\nthat feature anyway for next months.\n\n\n Marco\n"},{"id":"34108","messageId":"e5bfff550702100651j244e5a2flf02fb91dc71799b3@mail.gmail.com","threadId":"6755","inReplyTo":"e5bfff550702100648p6db5fc67vb5e4a04d40771922@mail.gmail.com","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-10T14:51:39Z","receivedAt":"2007-02-10T14:51:39Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/10/07, Marco Costalba wrote:\n> >\n> > You need a new version of _Git_ if you use that option.\n> >\n>\n> That's a true point. Altough if git 1.5 ships _without_ '--refresh'\n> option in 'git runstatus' for a porcelain tool point of view it means\n> *do forget* that option until next major release. There's no point in\n> adding the feature one day after git 1.5 is out; qgit will not use\n> that feature anyway for next months.\n>\n\nI could opt for shipping qgit 1.5.5 _without_ using '--refresh' and\nthen ship, as example in a month, qgit 1.5.6 that uses the feaure. But\nI can do this _only_ if git 1.5 has it.\n"},{"id":"34109","messageId":"Pine.LNX.4.63.0702101554170.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6755","inReplyTo":"e5bfff550702100648p6db5fc67vb5e4a04d40771922@mail.gmail.com","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-10T14:59:10Z","receivedAt":"2007-02-10T14:59:10Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 10 Feb 2007, Marco Costalba wrote:\n\n> On 2/10/07, Johannes Schindelin wrote:\n> > On Sat, 10 Feb 2007, Marco Costalba wrote:\n> > > On 2/10/07, Johannes Schindelin wrote:\n> > > > On Fri, 9 Feb 2007, Marco Costalba wrote:\n> > > >\n> > > > > I just need to know if current working directory is clean and report\n> > > > > back to qgit user, so read-only access would be ok for me.\n>\n> [... talking about a patch to introduce --refresh to git-status ...]\n>\n> Well, I tested the patch and indeed it helps a lot ;-)\n\nNot really. The thing is, git-status does a lot more than what you need. \nAnd what you need is _only_ what \"git diff --name-only HEAD\" does already!\n\nIt _also_ checks the index, it _also_ only checks the files with different \nstat information, but it does _not_ try to update the index and prepare a \nmessage to be displayed when committing.\n\nSo, what is the big problem about accepting that patching git-status for \none obscure use is wrong, wrong, wrong, when git-diff already does what is \nneeded???\n\nCiao,\nDscho\n"},{"id":"34110","messageId":"7vd54im4f2.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"e5bfff550702100325v5ce9ba1fx4b9b7adcc5040948@mail.gmail.com","subject":"Re: [PATCH 1/2] run_diff_{files,index}(): update calling convention.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-10T15:13:37Z","receivedAt":"2007-02-10T15:13:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> So in this case your patch that introduce '--refresh' option in 'git\n> runstatus' is not just a shortcut for 'git update-index' + 'git\n> runstatus' but adds some real value.\n>\n> One more reason for asking you to add it before 1.5 release ;-)\n\nThe thing is, it touches central part of the system by changing\nthe calling convention of two rather important functions. You\nmight have already fully tested that there is no regression for\ngit-runstatus, but it affects other callers as well. I tried to\nbe careful when I did the conversion but I am not 100% sure\nthere is no \"unintended side effects\".\n"},{"id":"34111","messageId":"e5bfff550702100745t4467d4eco30b2b66dc7f3bea7@mail.gmail.com","threadId":"6755","inReplyTo":"Pine.LNX.4.63.0702101554170.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-10T15:45:33Z","receivedAt":"2007-02-10T15:45:33Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/10/07, Johannes Schindelin wrote:\n> Hi,\n>\n> Not really. The thing is, git-status does a lot more than what you need.\n> And what you need is _only_ what \"git diff --name-only HEAD\" does already!\n>\n> It _also_ checks the index, it _also_ only checks the files with different\n> stat information, but it does _not_ try to update the index and prepare a\n> message to be displayed when committing.\n>\n> So, what is the big problem about accepting that patching git-status for\n> one obscure use is wrong, wrong, wrong, when git-diff already does what is\n> needed???\n>\nProbably I'm doing something wrong, but that's how working dir\ndetection is currently implemented in qgit:\n\nvoid Git::getDiffIndex() {\n\n\tQString status;\n\tif (!run(\"git status\", &status)) // git status refreshes the index,\nrun as first\n\t\treturn;\n\n\tif (!run(\"git diff-index HEAD\", &_wd.diffIndex))\n\t\treturn;\n\n\t// check for files already updated in cache, we will\n\t// save this information in status third field\n\tif (!run(\"git diff-index --cached HEAD\", &_wd.diffIndexCached))\n\t\treturn;\n\n ...... other stuff .....\n\n\nThe first call to git-status has been there for ages and with the only\ngoal to refesh the index so to avoid stale data in following 'git\ndiff-index' calls.\n\nIf I have understood correctly you suggest to remove that call because\nuseless? And rely 'git diff-index' info directly. Of course if there\nare no side effects I'will be happy to drop the call, but I'm not sure\nit's the safest way to go.\n\nAnother option would be to accept a broken working dir detection in\nthese corner cases. It's a realistic option and probably the best.\nIndeed also subsitute 'git status' with 'git runstatus' as long as I\nget back _all_ the repo files it seems to me a lesser option, IMHO\nit's better failing with empty case than have a big flow of incorrect\ndata.\n\nMarco\n"},{"id":"34112","messageId":"e5bfff550702100751v33e655fw6358234c23170d51@mail.gmail.com","threadId":"6755","inReplyTo":"7vd54im4f2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/2] run_diff_{files,index}(): update calling convention.","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-10T15:51:24Z","receivedAt":"2007-02-10T15:51:24Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/10/07, Junio C Hamano wrote:\n> \"Marco Costalba\" writes:\n>\n> > So in this case your patch that introduce '--refresh' option in 'git\n> > runstatus' is not just a shortcut for 'git update-index' + 'git\n> > runstatus' but adds some real value.\n> >\n> > One more reason for asking you to add it before 1.5 release ;-)\n>\n> The thing is, it touches central part of the system by changing\n> the calling convention of two rather important functions. You\n> might have already fully tested that there is no regression for\n> git-runstatus, but it affects other callers as well. I tried to\n> be careful when I did the conversion but I am not 100% sure\n> there is no \"unintended side effects\".\n>\n\nI understand this.\n"},{"id":"34113","messageId":"Pine.LNX.4.64.0702101049480.1757@xanadu.home","threadId":"6755","inReplyTo":"Pine.LNX.4.63.0702101554170.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-10T15:54:27Z","receivedAt":"2007-02-10T15:54:27Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 10 Feb 2007, Johannes Schindelin wrote:\n\n> So, what is the big problem about accepting that patching git-status for \n> one obscure use is wrong, wrong, wrong, when git-diff already does what is \n> needed???\n\nBecause git-status itself is conceptually a read-only operation, and \nhaving it barf on a read-only file system is justifiably a bug.\n\nBut I agree that attempting to fix it now is probably just too risky not \nto compromize the 1.5.0 release. Better leave it as a known issue for \nv1.5.0 and fix it later... especially if there is a possible workaround \nin the mean time.\n\n\nNicolas\n"},{"id":"34117","messageId":"7v1wkykmj1.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"e5bfff550702100651j244e5a2flf02fb91dc71799b3@mail.gmail.com","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-10T16:25:22Z","receivedAt":"2007-02-10T16:25:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n>> That's a true point. Altough if git 1.5 ships _without_ '--refresh'\n>> option in 'git runstatus' for a porcelain tool point of view it means\n>> *do forget* that option until next major release. There's no point in\n>> adding the feature one day after git 1.5 is out; qgit will not use\n>> that feature anyway for next months.\n>\n> I could opt for shipping qgit 1.5.5 _without_ using '--refresh' and\n> then ship, as example in a month, qgit 1.5.6 that uses the feaure. But\n> I can do this _only_ if git 1.5 has it.\n\nYou can run it once when you start up to see if --refresh is\nsupported with the git the user has, and keep that result\nthroughout the life of the qgit process (so you have to do the\ncheck only once).\n\nWhat would you do when working with older git anyway? You would\nneed to fall back on some code -- or would you require a certain\nversion of git to go with this version of qgit?\n\nAbout \"Cygwin and Linux NTFS seem to disagree with lstat(2)\"\nproblem. Is it really what is happening here? It might be an\ninteresting exercise to printf(3) the struct stat members in\nboth environments and find out where they disagree. It might\nturn out to be something trivial to fix for the filesystem guys.\nI am not personally interested in solving that problem myself\n(nor I am equipped to -- I do not have ready access to dual\nbooting Windows setup), but still it is interesting to find out\nwhat the issue is.\n"},{"id":"34118","messageId":"7vveiaj7y5.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"Pine.LNX.4.63.0702101554170.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-10T16:25:38Z","receivedAt":"2007-02-10T16:25:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> > > > > I just need to know if current working directory is clean and report\n>> > > > > back to qgit user, so read-only access would be ok for me.\n>>\n>> [... talking about a patch to introduce --refresh to git-status ...]\n>>\n>> Well, I tested the patch and indeed it helps a lot ;-)\n>\n> Not really. The thing is, git-status does a lot more than what you need. \n> And what you need is _only_ what \"git diff --name-only HEAD\" does already!\n>\n> It _also_ checks the index, it _also_ only checks the files with different \n> stat information, but it does _not_ try to update the index and prepare a \n> message to be displayed when committing.\n>\n> So, what is the big problem about accepting that patching git-status for \n> one obscure use is wrong, wrong, wrong, when git-diff already does what is \n> needed???\n\nIt really depends on what Marco means by \"if cwd is clean\".\n\nIf by \"clean\" Marco means \"no differences after discarding cache\ncleanliness information\", \"git-diff\" is not quite it, as it\nshows the differences including the cleanliness of the cache\nentry.\n\n\"git-status\", as Marco found out in the message that started\nthis thread, loses the cache cleanliness information when it\nruns [*1*].\n\nIf he cares about cache cleanliness information, \"git-diff\" is\nthe right thing to use, and using \"git status\" is wrong -- it\nnot only does more than he needs (as you pointed out), it loses\ninformation, which may be worse, depending on why he wants to\nknow.\n\n[Footnote]\n\n*1* To achieve that, it has to write into the repository.\n\nIs it wrong for \"git-status\" to be losing the cache cleanliness\ninformation? The intended audience of that program is those who\nare about to make a commit in the repository, as they are asking\n\"what would I be committing?\" Up to that point, they may have\ncared about the reminder they get from \"git diff\" that they\nedited a file and then ended up reverting the whole edit they\ndid to that file (I find that empty diff from \"git diff\" often\nvery useful, although I felt \"Huh?\" when I was new to git).\nBut when they ask \"git status\", they care more about the real\nchange, and at that point (since they feel they may be ready to\nmake a commit -- and that is the whole point of running\n\"git-status\") they do want to lose the cache cleanliness\ninformation. So \"git-status\" to be read-write application to\ndiscard the cache-cleanliness information is probably a good\nthing.\n"},{"id":"34119","messageId":"7vr6syj7uw.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"Pine.LNX.4.64.0702101049480.1757@xanadu.home","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-10T16:27:35Z","receivedAt":"2007-02-10T16:27:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Sat, 10 Feb 2007, Johannes Schindelin wrote:\n>\n>> So, what is the big problem about accepting that patching git-status for \n>> one obscure use is wrong, wrong, wrong, when git-diff already does what is \n>> needed???\n>\n> Because git-status itself is conceptually a read-only operation, and \n> having it barf on a read-only file system is justifiably a bug.\n\nI do not 100% agree that it is conceptually a read-only operation.\n"},{"id":"34120","messageId":"e5bfff550702100835x6d5c0d40y42b3fe0f50f78fd7@mail.gmail.com","threadId":"6755","inReplyTo":"7vveiaj7y5.fsf@assigned-by-dhcp.cox.net","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-10T16:35:44Z","receivedAt":"2007-02-10T16:35:44Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/10/07, Junio C Hamano wrote:\n>\n> But when they ask \"git status\", they care more about the real\n> change, and at that point (since they feel they may be ready to\n> make a commit -- and that is the whole point of running\n> \"git-status\") they do want to lose the cache cleanliness\n> information. So \"git-status\" to be read-write application to\n> discard the cache-cleanliness information is probably a good\n> thing.\n>\n\nThe \"let's see what I'm going to commit today\" it's definitely the way\nI and probably most of qgit users look at the status info shown in\nmain view left bottom pane and also in commit dialog.\n"},{"id":"34121","messageId":"Pine.LNX.4.64.0702101131070.1757@xanadu.home","threadId":"6755","inReplyTo":"7vr6syj7uw.fsf@assigned-by-dhcp.cox.net","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-10T16:40:53Z","receivedAt":"2007-02-10T16:40:53Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 10 Feb 2007, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > On Sat, 10 Feb 2007, Johannes Schindelin wrote:\n> >\n> >> So, what is the big problem about accepting that patching git-status for \n> >> one obscure use is wrong, wrong, wrong, when git-diff already does what is \n> >> needed???\n> >\n> > Because git-status itself is conceptually a read-only operation, and \n> > having it barf on a read-only file system is justifiably a bug.\n> \n> I do not 100% agree that it is conceptually a read-only operation.\n\nIt is. It's the technical issue that makes it not so. But when a user \nasks for a status, he's clearly not expecting to _write_ anything, even \nless for the command to fail if the file system is read-only. This is \nlike if a file system driver refused to open a file when the file system \nis mounted read-only just because it cannot update the file's atime on \ndisk.\n\nJust like the atime example, we may refresh the index while at it when \npreparing the status results. This is a valid technical concern. But \nit for sure should not be mandatory for the command to succeed if the \nfile system is read-only.\n\n\nNicolas\n"},{"id":"34122","messageId":"7vmz3mj6yo.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"Pine.LNX.4.64.0702101131070.1757@xanadu.home","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-10T16:46:55Z","receivedAt":"2007-02-10T16:46:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Sat, 10 Feb 2007, Junio C Hamano wrote:\n>\n>> Nicolas Pitre writes:\n>> ...\n>> > Because git-status itself is conceptually a read-only operation, and \n>> > having it barf on a read-only file system is justifiably a bug.\n>> \n>> I do not 100% agree that it is conceptually a read-only operation.\n>\n> It is. It's the technical issue that makes it not so.\n\nI do not think so. It is a workflow issue that user indicates\nthe cache cleanliness information does not matter anymore.\n\nIs it wrong for \"git-status\" to be losing the cache cleanliness\ninformation? The intended audience of that program is those who\nare about to make a commit in the repository, as they are asking\n\"what would I be committing?\" Up to that point, they may have\ncared about the reminder they get from \"git diff\" that they\nedited a file and then ended up reverting the whole edit they\ndid to that file (I find that empty diff from \"git diff\" often\nvery useful, although I felt \"Huh?\" when I was new to git).\nBut when they ask \"git status\", they care more about the real\nchange, and at that point (since they feel they may be ready to\nmake a commit -- and that is the whole point of running\n\"git-status\") they do want to lose the cache cleanliness\ninformation. So \"git-status\" to be read-write application to\ndiscard the cache-cleanliness information is probably a good\nthing.\n"},{"id":"34124","messageId":"Pine.LNX.4.64.0702101154130.1757@xanadu.home","threadId":"6755","inReplyTo":"7vmz3mj6yo.fsf@assigned-by-dhcp.cox.net","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-10T17:03:52Z","receivedAt":"2007-02-10T17:03:52Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 10 Feb 2007, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > On Sat, 10 Feb 2007, Junio C Hamano wrote:\n> >\n> >> Nicolas Pitre writes:\n> >> ...\n> >> > Because git-status itself is conceptually a read-only operation, and \n> >> > having it barf on a read-only file system is justifiably a bug.\n> >> \n> >> I do not 100% agree that it is conceptually a read-only operation.\n> >\n> > It is. It's the technical issue that makes it not so.\n> \n> I do not think so. It is a workflow issue that user indicates\n> the cache cleanliness information does not matter anymore.\n\nYou're making assumption about work flows and using that to justify \ncommand implementation flaws. This is not exactly \"user friendly\".\n\n> Is it wrong for \"git-status\" to be losing the cache cleanliness\n> information? The intended audience of that program is those who\n> are about to make a commit in the repository, as they are asking\n> \"what would I be committing?\" Up to that point, they may have\n> cared about the reminder they get from \"git diff\" that they\n> edited a file and then ended up reverting the whole edit they\n> did to that file (I find that empty diff from \"git diff\" often\n> very useful, although I felt \"Huh?\" when I was new to git).\n> But when they ask \"git status\", they care more about the real\n> change, and at that point (since they feel they may be ready to\n> make a commit -- and that is the whole point of running\n> \"git-status\") they do want to lose the cache cleanliness\n> information.\n\nI don't dispute that. But git-status should certainly not be restricted \n_only_ to that usage pattern.\n\n> So \"git-status\" to be read-write application to\n> discard the cache-cleanliness information is probably a good\n> thing.\n\nIt is... when the file system lets you write. Like I said this is a \ntechnically good thing to do.\n\nBut a command that is called \"status\" should provide a \"status\" even if \nthe file system is read-only nevertheless. The index updating business \nthat is done behind the scene is and should be an opportunistic \noptimization, but it should not prevent status reporting.\n\nIt is pretty expected that a \"commit\" command would fail if the file \nsystem is ro, but not a \"status\" command. And this is true \nirrespectively of whatever workflow you might be most likely to use the \n\"status\" command for.\n\n\nNicolas\n"},{"id":"34127","messageId":"Pine.LNX.4.64.0702100913020.8424@woody.linux-foundation.org","threadId":"6755","inReplyTo":"Pine.LNX.4.64.0702101131070.1757@xanadu.home","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-10T17:37:58Z","receivedAt":"2007-02-10T17:37:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 10 Feb 2007, Nicolas Pitre wrote:\n> > >\n> > > Because git-status itself is conceptually a read-only operation, and \n> > > having it barf on a read-only file system is justifiably a bug.\n> > \n> > I do not 100% agree that it is conceptually a read-only operation.\n> \n> It is.\n\nIt really isn't. \n\nIt's not even a \"technical issue\". It's a fundamental optimization. Sure, \nyou can call optimizations just \"technical issues\", but the fact is, it's \none of the things that makes git so _usable_ on large archives. At some \npoint, an \"optimization\" is no longer just about making things slightly \nfaster, it's about something much bigger, and has real semantic meaning.\n\nSo the fact is, \"git status\" _needs_ to refresh the index. Because if it \ndoesn't, you'll see every file that doesn't match the index as \"dirty\", \nand that is not just a \"technical issue\".\n\nAnd yes, doing an \"internal\" refresh, like Junio's patch does, hides the \nissue, but it hides it BY MAKING THE OPTIMIZATION POINTLESS!\n\nI suspect Marco is testing some reasonably small git archive. With \nsomething like git itself, with less than a thousand files (and most of \nthem fairly small, so rehashing them all is quick), the optimization may \n_feel_ like just a small technical detail.\n\nNow, try the same thing on the Linux kernel or somethign similar, \nespecially with cold caches or not a huge amount of memory.\n\nThat \"technical issue\" is what makes \"git status\" take less than a second \nfor me, and only a bit longer if things aren't cached - because we don't \nactually have to read all the file data. \n\nNow, it so happens that _if_ things are cached, at least under Linux, \ncached IO is so _incredibly_ fast that you won't even realize how \nexpensive an operation you missed. I can SHA1 every file in the kernel \narchive (21432 files right now - 8 million LOC, and 230MB of data) in less \nthan a couple of seconds. But that's only because it's all cached for me \nanyway, because I tend to run with lots of RAM, and I do things like \"git \ngrep so-and-so\" which brings it all into cache.\n\nBut try the same thing without caches.\n\nHere's something you can do under linux:\n\n\tsudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"\n\tgit read-tree HEAD\n\ttime git update-index --refresh\n\nand it takes me *40* seconds. That's with quite a fast disk too - it would \ntake a whole lot longer on a laptop.\n\nThen, try it _without_ having to actually read all files, because the \nindex is already up-to-date:\n\n\tsudo sh -c \"echo 3 > /proc/sys/vm/drop_caches\"\n\ttime git update-index --refresh\n\nand not it took *4* seconds. That's because it didn't actually need to \nread any file data, it could just do the stats.\n\nThen, cached:\n\n\t# bring it all in again\n\tgit grep something-or-other\n\n\t# invalidate the index cache\n\tgit read-tree HEAD\n\ttime git update-index --refresh\n\nand I can do it under *2* seconds - because Linux is just damn good at \ncached IO, so I can read all those 21-thousand files and 235MB of data \nfrom the kernel cache in less than a second.\n\nBut finally, do it with caches _and_ the index in place:\n\n\ttime git update-index --refresh\n\nand it now takes 0.06 seconds. It's what allows me to do \"git diff\" on the \nkernel tree in a tenth of a second.\n\nTHIS IS NOT \"JUST A TECHNICAL ISSUE\". \n\nWhen the difference is 40 seconds vs 4 (uncached), or 2 seconds vs 0.06, \nit's not about \"just an optimization\" any more. At that point, it's about \n\"unusable vs usable\".\n\nAnd yeah, waiting 40 seconds for a global \"diff\" for a big project may be \nsomething that a person coming from CVS considers to be just par for the \ncourse. Maybe I'm just unreasonable. But I think it's a _bug_ if I can't \nget a small diff in about a tenth of a second. It needs to be so fast that \nI never even _think_ about it.\n\nAnd the index is what makes it so. \n\nAnd that's why it's important to keep the index up-to-date. If we have \noperations that allow the index to just *stay* non-coherent, like the \nsuggested \"git runstatus --refresh\" that doesn't actually write it back, \nthen that's a *bad* thing. \n\nI think it would be much better if \"git status\" always wrote the refreshed \nindex file. It could then choose to ignore any errors if they happen, \nbecause if you have a broken setup like the NTFS read-only thing, then \ntough, it's broken, but git can't do anythign about it. But people should \nbe aware that yes, \"git status\" absolutely _needs_ to write the index \nfile. \n\nIt is *not* a read-only operation. The index is too important to be \nconsidered \"just a technical issue\". \n\n\t\tLinus\n"},{"id":"34129","messageId":"7v1wkxki4a.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"Pine.LNX.4.64.0702101154130.1757@xanadu.home","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-10T18:00:37Z","receivedAt":"2007-02-10T18:00:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> You're making assumption about work flows and using that to justify \n> command implementation flaws. This is not exactly \"user friendly\".\n\nI do not necessarily agree that making the command to follow a\nBCP workflow is \"user unfriendly\", but that does not pertain\nwhat I will end up saying in this message, which is to agree\nwith you.\n\n> But a command that is called \"status\" should provide a \"status\" even if \n> the file system is read-only nevertheless. The index updating business \n> that is done behind the scene is and should be an opportunistic \n> optimization, but it should not prevent status reporting.\n\nFair enough. That leaves us two options.\n\n (0) Do nothing.\n\n (1) We keep the current \"git-status [-v] [-a] [[-i|-o] ]\"\n command line and do the necessary index manipulation\n in-core without writing it out (see git-commit.sh for\n details of what it involves). \n\n (2) We drop the support for any command line parameter from\n \"git-status\", apply my two patches for Marco to\n \"git-runstatus\", and rename \"git-runstatus\" to\n \"git-status\".\n\nIf I have to pick between the two, I would probably pick (2).\nWhile (1) would essentially mean doing \"git-commit\" entirely\nin-core without writing the index out until we really make the\ncommit, which is a good thing in itself in the longer term, it\nis out of the question this late in the game for 1.5.0.\n\nAnd now I think what Linus suggests also make sense -- we could\ntweak (2) so that git-runstatus actually writes the refreshed\nindex out when it finds that it _can_ write it (and drop\nsubsequent internal refresh).\n\nNow, I am heading out.\n"},{"id":"34132","messageId":"20070210184313.GF25607@thunk.org","threadId":"6755","inReplyTo":"7v1wkxki4a.fsf@assigned-by-dhcp.cox.net","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-02-10T18:43:13Z","receivedAt":"2007-02-10T18:43:13Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Feb 10, 2007 at 10:00:37AM -0800, Junio C Hamano wrote:\n> (1) We keep the current \"git-status [-v] [-a] [[-i|-o] ]\"\n> command line and do the necessary index manipulation\n> in-core without writing it out (see git-commit.sh for\n> details of what it involves). \n> \n> (2) We drop the support for any command line parameter from\n> \"git-status\", apply my two patches for Marco to\n> \"git-runstatus\", and rename \"git-runstatus\" to\n> \"git-status\".\n> \n> If I have to pick between the two, I would probably pick (2).\n> While (1) would essentially mean doing \"git-commit\" entirely\n> in-core without writing the index out until we really make the\n> commit, which is a good thing in itself in the longer term, it\n> is out of the question this late in the game for 1.5.0.\n\nIf you end up doing (2), may I suggest making the functionality of\n\"git-status\" today available as \"git-commit -n\"? It is something\nuseful, so we shouldn't lose it, and -n meaning --no-action is a well\naccepted convention for Unix commands.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"34133","messageId":"Pine.LNX.4.64.0702101329320.1757@xanadu.home","threadId":"6755","inReplyTo":"Pine.LNX.4.64.0702100913020.8424@woody.linux-foundation.org","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-10T18:51:08Z","receivedAt":"2007-02-10T18:51:08Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 10 Feb 2007, Linus Torvalds wrote:\n\n> It is *not* a read-only operation. The index is too important to be \n> considered \"just a technical issue\". \n\nThere is just a semantic issue that you seem to overlook completely.\n\nAccording to the dictionarry, \"status\" is a synonym to a \"state\". It is \n_not_ an action.\n\nSo, from a _user_ perspective, the git-status command should give back a \n\"status\". Of _course_ the user will benefit from the index updating \nbusiness, but as important as this update might be (and I do agree that \nit is fundamental for GIT's performance), this is still a by-product of \nthe \"status\" command.\n\nTherefore, the fact that the index isn't writable should not prevent \ngit-status from providing the very result for which its name was chosen. \nThe index might as well be brought up to date on disk the next time the \nfile system is writable.\n\n\nNicolas\n"},{"id":"34134","messageId":"Pine.LNX.4.64.0702101351430.1757@xanadu.home","threadId":"6755","inReplyTo":"7v1wkxki4a.fsf@assigned-by-dhcp.cox.net","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-10T18:53:44Z","receivedAt":"2007-02-10T18:53:44Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 10 Feb 2007, Junio C Hamano wrote:\n\n> (0) Do nothing.\n> \n> (1) We keep the current \"git-status [-v] [-a] [[-i|-o] ]\"\n> command line and do the necessary index manipulation\n> in-core without writing it out (see git-commit.sh for\n> details of what it involves). \n> \n> (2) We drop the support for any command line parameter from\n> \"git-status\", apply my two patches for Marco to\n> \"git-runstatus\", and rename \"git-runstatus\" to\n> \"git-status\".\n> \n> If I have to pick between the two, I would probably pick (2).\n> While (1) would essentially mean doing \"git-commit\" entirely\n> in-core without writing the index out until we really make the\n> commit, which is a good thing in itself in the longer term, it\n> is out of the question this late in the game for 1.5.0.\n\nAnd don't get me wrong. I think that for 1.5.0 you should really do (0).\n\n\nNicolas\n"},{"id":"34135","messageId":"20070210185652.GG25607@thunk.org","threadId":"6755","inReplyTo":"Pine.LNX.4.64.0702101351430.1757@xanadu.home","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-02-10T18:56:52Z","receivedAt":"2007-02-10T18:56:52Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Feb 10, 2007 at 01:53:44PM -0500, Nicolas Pitre wrote:\n> On Sat, 10 Feb 2007, Junio C Hamano wrote:\n> \n> > (0) Do nothing.\n> > \n> > (1) We keep the current \"git-status [-v] [-a] [[-i|-o] ]\"\n> > command line and do the necessary index manipulation\n> > in-core without writing it out (see git-commit.sh for\n> > details of what it involves). \n> > \n> > (2) We drop the support for any command line parameter from\n> > \"git-status\", apply my two patches for Marco to\n> > \"git-runstatus\", and rename \"git-runstatus\" to\n> > \"git-status\".\n> > \n> > If I have to pick between the two, I would probably pick (2).\n> > While (1) would essentially mean doing \"git-commit\" entirely\n> > in-core without writing the index out until we really make the\n> > commit, which is a good thing in itself in the longer term, it\n> > is out of the question this late in the game for 1.5.0.\n> \n> And don't get me wrong. I think that for 1.5.0 you should really do (0).\n\nWell, if we're going to change the semantics of git-status, we would\nhave to do it in 1.5.0 or wait until 1.6.0, wouldn't we?\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"34137","messageId":"e5bfff550702101108k5dabd8d5o2487cc87bb1eafc7@mail.gmail.com","threadId":"6755","inReplyTo":"Pine.LNX.4.64.0702101351430.1757@xanadu.home","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-02-10T19:08:53Z","receivedAt":"2007-02-10T19:08:53Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 2/10/07, Nicolas Pitre wrote:\n> On Sat, 10 Feb 2007, Junio C Hamano wrote:\n>\n> > (0) Do nothing.\n> >\n> > (1) We keep the current \"git-status [-v] [-a] [[-i|-o] ]\"\n> > command line and do the necessary index manipulation\n> > in-core without writing it out (see git-commit.sh for\n> > details of what it involves).\n> >\n> > (2) We drop the support for any command line parameter from\n> > \"git-status\", apply my two patches for Marco to\n> > \"git-runstatus\", and rename \"git-runstatus\" to\n> > \"git-status\".\n> >\n> > If I have to pick between the two, I would probably pick (2).\n> > While (1) would essentially mean doing \"git-commit\" entirely\n> > in-core without writing the index out until we really make the\n> > commit, which is a good thing in itself in the longer term, it\n> > is out of the question this late in the game for 1.5.0.\n>\n> And don't get me wrong. I think that for 1.5.0 you should really do (0).\n>\n\nI agree on doing (0) for 1.5.0 and the following Linus lines make me\nwonder if is better doing (0) also after 1.5.0\n\n> So the fact is, \"git status\" _needs_ to refresh the index. Because if it\n> doesn't, you'll see every file that doesn't match the index as \"dirty\",\n> and that is not just a \"technical issue\".\n>\n> And yes, doing an \"internal\" refresh, like Junio's patch does, hides the\n> issue, but it hides it BY MAKING THE OPTIMIZATION POINTLESS!\n>\n> I suspect Marco is testing some reasonably small git archive. With\n> something like git itself, with less than a thousand files (and most of\n> them fairly small, so rehashing them all is quick), the optimization may\n> _feel_ like just a small technical detail.\n\nIf current 'git runstatus' on a NTFS directory, Linux side, show as\ndirty _all_ the repo files, then in case of big repos, as Linus\npointed out, a possible future 'git runstatus --refresh' will be\nterribly slow because must filter out as false positives _all_ the\nrepo files. And worst, have to do it *any time* it is run.\n\nSo perhaps the two patches of Junio _seems_ to work to me just because\nrepo is small, is qgit4 indeed, but on a Linux tree would be veeery\nslow, so slow that probably is better to avoid completely and report\nquickly to user an empty set, being a corner case user will understand\n;-)\n\nMarco\n\nP.S: I know I'm looking for flames but, if git-status HAVE to write\nthe index and if 'status', as Nicolas points out, is a word that\nsuggest a read only function, why don't change the name of the\ncommand.....'git sync-index' as example.\n"},{"id":"34139","messageId":"Pine.LNX.4.63.0702102135080.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6755","inReplyTo":"7v1wkykmj1.fsf@assigned-by-dhcp.cox.net","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-10T20:36:33Z","receivedAt":"2007-02-10T20:36:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 10 Feb 2007, Junio C Hamano wrote:\n\n> About \"Cygwin and Linux NTFS seem to disagree with lstat(2)\"\n> problem. Is it really what is happening here?\n\nProbably. AFAIR Windows lacks some important information, which is filled \nwith zeroes by Cygwin.\n\nNote that this problem already arises between Cygwin and MinGW, and it \ncannot be fixed: Cygwin _has_ symlinks, while MinGW has _not_.\n\nCiao,\nDscho\n"},{"id":"34140","messageId":"Pine.LNX.4.63.0702102137110.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6755","inReplyTo":"Pine.LNX.4.64.0702101049480.1757@xanadu.home","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-10T20:40:41Z","receivedAt":"2007-02-10T20:40:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 10 Feb 2007, Nicolas Pitre wrote:\n\n> On Sat, 10 Feb 2007, Johannes Schindelin wrote:\n> \n> > So, what is the big problem about accepting that patching git-status for \n> > one obscure use is wrong, wrong, wrong, when git-diff already does what is \n> > needed???\n> \n> Because git-status itself is conceptually a read-only operation, and \n> having it barf on a read-only file system is justifiably a bug.\n\nJust to fuel the fire even more: Does it make _sense_ running git-status \nwhen you cannot write? I mean, the only reasonable use cases to ask \ngit-status (even interpreting it in the \"state\" sense you are proposing), \nis when you are _working_ on the files. Which you cannot do without write \naccess.\n\nBTW I was not aware that \"git diff --name-only HEAD\" would not check if \nthe file is differing or not, but even then, it is arguably the right \nthing for qgit to show what the index' idea of the status is.\n\nCiao,\nDscho\n"},{"id":"34155","messageId":"7vtzxtdwz9.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"Pine.LNX.4.64.0702100913020.8424@woody.linux-foundation.org","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-11T06:33:46Z","receivedAt":"2007-02-11T06:33:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sat, 10 Feb 2007, Nicolas Pitre wrote:\n>> > >\n>> > > Because git-status itself is conceptually a read-only operation, and \n>> > > having it barf on a read-only file system is justifiably a bug.\n>> > \n>> > I do not 100% agree that it is conceptually a read-only operation.\n>> \n>> It is.\n>\n> It really isn't. \n>\n> It's not even a \"technical issue\". It's a fundamental optimization. Sure, \n> you can call optimizations just \"technical issues\", but the fact is, it's\n> one of the things that makes git so _usable_ on large archives. At some \n> point, an \"optimization\" is no longer just about making things slightly \n> faster, it's about something much bigger, and has real semantic meaning.\n> ...\n> THIS IS NOT \"JUST A TECHNICAL ISSUE\". \n> ...\n> And the index is what makes it so. \n>\n> And that's why it's important to keep the index up-to-date.\n\nI think a one paragraph summary of your argument is:\n\n - index is a good thing -- it is what makes the difference\n between usable and unusable.\n\n - git-status needs to refresh the index in order to do its\n thing efficiently and usably _anyway_, so once it spends\n cycles to do so, it is senseless not to write the refreshed\n index out when it can.\n\nI do not think anybody disputes that in a repository with 20k+\npaths, it is sensible to leave the index stat-dirty for all\npaths. But I think your example\n\n\tread-tree HEAD\n\nmisses the point by stressing the importance of index too much.\nIndex is important for the usability and I do not think anybody\nis disputing it.\n\nThe thing is, nobody switches the index that way without running\n\"update-index --refresh\" afterwards. Normal people would use\ngit-reset to switch to a different tree object, and the command\ndoes that for you. If you are a hardcore, you would know to use\n\"read-tree -m HEAD\" at least to avoid making paths unnecessarily\nstat-dirty. Your example, while it is valid and demonstrates\nwhy the index is a good thing very well, is simply not part of\na normal workflow and not very relevant when discussing the\nperformance ramifications of what state \"git-status\" should\nleave the index in.\n\nWhen I said \"calling 'update-index --refresh' in git-status\nloses stat-dirtiness information\", I was certainly _NOT_ talking\nabout losing the information that 20k+ paths used to be\nstat-dirty because the user did \"read-tree HEAD\" earlier.\n\nAt least for me, it is very normal to do something like this.\n\n * start from a clean index.\n\n * edit cache.h, diff.h, and diff-lib.c.\n\n * stop, think, and realize that my earlier edit to change one\n function prototype in diff.h was not needed, and revert the\n change to that line still in the editor.\n\n * fix things up further by editing other files.\n\nAnd then, I would run \"git diff\" to see where I am. I still\nremember that I touched diff.h and I also remember that I once\nchanged a function prototype but then decided the change was not\nnecessary after all, but I do not remember if I changed anything\nelse in the file. It is _very_ assuring to see the emptiness\nthat follows \"git diff --git\" header for diff.h in such a case.\nSeeing the path to be stat-dirty is a very good thing for me,\nbecause otherwise I might lose a few seconds thinking that what\nI thought I touched might have been cache.h and not diff.h.\n\nTo me, running \"git status\" is \"wrapping things up\" step. I do\nnot need that stat-dirty assurance \"git diff\" gave me at that\npoint. Not seeing diff.h in \"modified but updated\" list is a\ngood thing. And in my workflow, after that 'wrapping things up\"\nstep, I do not need that stat-dirty assurance _anymore_.\n\nI think Nico is correct to point out that \"not _anymore_\" part\nof the above reasoning of mine assumes _my_ workflow and\npreference, and I think that is a valid point. Not saving the\nrefreshed index would make the stat-dirtiness for diff.h to come\nback, which would be inconvenient and annoying to me.\n\nBut the user might want to keep it stat-dirty after running\n\"git-status\". People in \"not _anymore_\" camp like me can throw\nthe stat-dirtiness away by \"update-index --refresh\". I do not\nthink he (or anybody) is advocating to keep 20k+ paths in\nstat-dirty state (arguably, \"artificially\" due to use of\n\"read-tree HEAD\"), so your example using \"read-tree HEAD\" only\nconfuses the discussion.\n\nHaving said all that, I do agree with you that git-status should\nthrow that stat-dirtiness information away by saving the\nrefreshed index. Doing otherwise is annoying to me as I already\nsaid, and I do not think of a valid reason for the user to want\nto keep stat-dirtiness information after running \"git-status\",\nbecause to me the whole point of running \"git-status\" is to\nstart wrapping things up.\n"},{"id":"34157","messageId":"20070211072358.GB2082@spearce.org","threadId":"6755","inReplyTo":"Pine.LNX.4.64.0702100913020.8424@woody.linux-foundation.org","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-11T07:23:58Z","receivedAt":"2007-02-11T07:23:58Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> It's not even a \"technical issue\". It's a fundamental optimization. Sure, \n> you can call optimizations just \"technical issues\", but the fact is, it's \n> one of the things that makes git so _usable_ on large archives. At some \n> point, an \"optimization\" is no longer just about making things slightly \n> faster, it's about something much bigger, and has real semantic meaning.\n> \n> So the fact is, \"git status\" _needs_ to refresh the index. Because if it \n> doesn't, you'll see every file that doesn't match the index as \"dirty\", \n> and that is not just a \"technical issue\".\n\nIndeed. Except that `git-update-index --refresh` is itself not\nvery fast on Cygwin+NTFS and large projects (about the size of\nthe kernel). So git-status is a real slouch there. Not running\n`git update-index --refresh` saves at least a couple of seconds.\n\nThis is why git-gui lets you disable the refresh, and is part of\nthe reason why it computes the status on its own by diff-index,\ndiff-files and ls-files --others.\n \n> THIS IS NOT \"JUST A TECHNICAL ISSUE\". \n> \n> When the difference is 40 seconds vs 4 (uncached), or 2 seconds vs 0.06, \n> it's not about \"just an optimization\" any more. At that point, it's about \n> \"unusable vs usable\".\n> \n> And yeah, waiting 40 seconds for a global \"diff\" for a big project may be \n> something that a person coming from CVS considers to be just par for the \n> course. Maybe I'm just unreasonable. But I think it's a _bug_ if I can't \n> get a small diff in about a tenth of a second. It needs to be so fast that \n> I never even _think_ about it.\n\nYes. Which is why if git-gui finds a file that has an empty diff,\nbut that was reported as modified by diff-files, it tells the user\nits about to go waste a few seconds running `update-index --refresh`,\nthen does so.\n\nIn practice I've found it rare that a file is dirty in the index,\nbut is not actually modified. The typical culprit appears to\nactually be the virus scanner on a Windows system. For some reason\nit feels a need to modify some random XML 'source' files that are\ntracked by Git. Out of 30,000 files it likes to modify about 100.\n*sigh* At least I have Git to tell me it didn't change any content.\n \n> I think it would be much better if \"git status\" always wrote the refreshed \n> index file. It could then choose to ignore any errors if they happen, \n> because if you have a broken setup like the NTFS read-only thing, then \n> tough, it's broken, but git can't do anythign about it. But people should \n> be aware that yes, \"git status\" absolutely _needs_ to write the index \n> file. \n\nNot only that, but I think we can do much better with git-runstatus\nthan we do now. If we scan the working directory (to search for\nuntracked files), and we walk the index in parallel, we can update\nthe index with new stat data if necessary.\n\nOf course that doesn't matter much on Linux; its VFS operations\ndon't take hours.\n\n-- \nShawn.\n"},{"id":"34193","messageId":"7vbqk0cq7i.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"Pine.LNX.4.63.0702102135080.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-11T21:57:37Z","receivedAt":"2007-02-11T21:57:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Sat, 10 Feb 2007, Junio C Hamano wrote:\n>\n>> About \"Cygwin and Linux NTFS seem to disagree with lstat(2)\"\n>> problem. Is it really what is happening here?\n>\n> Probably. AFAIR Windows lacks some important information, which is filled \n> with zeroes by Cygwin.\n\nIf NTFS driver in the Linux kernel is filling that with zeroes\nthe same way then there won't be differences, right?\n"},{"id":"34195","messageId":"Pine.LNX.4.63.0702112305580.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6755","inReplyTo":"7vbqk0cq7i.fsf@assigned-by-dhcp.cox.net","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-11T22:09:20Z","receivedAt":"2007-02-11T22:09:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 11 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Sat, 10 Feb 2007, Junio C Hamano wrote:\n> >\n> >> About \"Cygwin and Linux NTFS seem to disagree with lstat(2)\"\n> >> problem. Is it really what is happening here?\n> >\n> > Probably. AFAIR Windows lacks some important information, which is filled \n> > with zeroes by Cygwin.\n> \n> If NTFS driver in the Linux kernel is filling that with zeroes\n> the same way then there won't be differences, right?\n\nMaybe. Although I am quite certain that you'd break something by that.\n\nBut after all, this is one really obscure corner case you have there, and \nyou are not really working on the repository on Linux either, since you \nhave it mounted readonly.\n\nI absolutely have no intention to \"fix\" performance or other issues for \nthat case.\n\nCiao,\nDscho\n"},{"id":"34197","messageId":"Pine.LNX.4.63.0702112325310.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6755","inReplyTo":"Pine.LNX.4.63.0702112305580.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-11T22:28:52Z","receivedAt":"2007-02-11T22:28:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"On Sun, 11 Feb 2007, Johannes Schindelin wrote:\n\n> On Sun, 11 Feb 2007, Junio C Hamano wrote:\n> \n> > If NTFS driver in the Linux kernel is filling that [lstat information \n> > which Windows does not provide] with zeroes the same way then there \n> > won't be differences, right?\n> \n> Maybe. Although I am quite certain that you'd break something by that.\n\nClarification: I am not a filesystem programmer, and as such do not know \nabout this issue as much as I would like. But I am quite confident that \ninodes are an important tool to provide performance. Or something else.\n\nAnyway, I think it is rarely advisable to imitate MS Windows, and as I \nmade clean, Marco's particular situation does not seem relevant to me.\n\nCiao,\nDscho \n"},{"id":"34198","messageId":"7vsldcba3k.fsf@assigned-by-dhcp.cox.net","threadId":"6755","inReplyTo":"Pine.LNX.4.63.0702112305580.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-11T22:30:55Z","receivedAt":"2007-02-11T22:30:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Sun, 11 Feb 2007, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> > On Sat, 10 Feb 2007, Junio C Hamano wrote:\n>> >\n>> >> About \"Cygwin and Linux NTFS seem to disagree with lstat(2)\"\n>> >> problem. Is it really what is happening here?\n>> >\n>> > Probably. AFAIR Windows lacks some important information, which is filled \n>> > with zeroes by Cygwin.\n>> \n>> If NTFS driver in the Linux kernel is filling that with zeroes\n>> the same way then there won't be differences, right?\n>\n> Maybe. Although I am quite certain that you'd break something by that.\n>\n> But after all, this is one really obscure corner case you have there, and \n> you are not really working on the repository on Linux either, since you \n> have it mounted readonly.\n>\n> I absolutely have no intention to \"fix\" performance or other issues for \n> that case.\n\nAh, you misread me. What I was trying to drive at was if we\nfind the subtle difference between Cygwin's lstat(2) emulation\nand lstat(2) result from the NTFS driver in the Linux kernel, we\ncould start and fuel flamewar on _other_ lists (namely, kernel\nand Cygwin) saying \"you guys are inconsistent which inconvenience\napplications great deal\".\n\nAnd watching other people flame each other is a lot more fun\nthan flamewar raging close to home ;-).\n"},{"id":"34207","messageId":"Pine.LNX.4.63.0702120018110.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6755","inReplyTo":"7vsldcba3k.fsf@assigned-by-dhcp.cox.net","subject":"Re: 'git status' is not read-only fs friendly","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-11T23:24:24Z","receivedAt":"2007-02-11T23:24:24Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 11 Feb 2007, Junio C Hamano wrote:\n\n> Ah, you misread me. What I was trying to drive at was if we find the \n> subtle difference between Cygwin's lstat(2) emulation and lstat(2) \n> result from the NTFS driver in the Linux kernel, we could start and fuel \n> flamewar on _other_ lists (namely, kernel and Cygwin) saying \"you guys \n> are inconsistent which inconvenience applications great deal\".\n\nI have no access to cygwin right now, so I'll argue using MinGW instead.\n\nAs I already said, I do not know what would happen if we touched st_ino. \nWe'd likely have to touch it, since it takes 2 bytes on MinGW, and 4 bytes \non Linux. Also, IIRC Cygwin fakes the inodes; and it depends on the Cygwin \nversion, how it does it.\n\nAlso, we check st_uid and st_gid explicitely, which is more a problem to \nbe solved by the person mounting the filesystem than the person \nmaintaining the filesystem driver.\n\nAFAICT we do not use st_dev anyway.\n\n> And watching other people flame each other is a lot more fun than \n> flamewar raging close to home ;-).\n\nSometimes I find them fun here, too. That is, if it is not such a tiring \nflamewar as the renaming issues which creep up regularly.\n\nCiao,\nDsho\n"}]}