Noticed-by: Andy Parkins
Signed-off-by: Alex Riesen <redacted>
--
On Thu, May 20, 2010 at 15:28, Junio C Hamano [off-list ref] wrote:
As to the not-working-configuration I don't remember the codepath well, so
sorry but no answer from me right now.
Maybe because we do a (kind of) gentle status run on submodules
whether the status.SubmoduleSummary set or not. Usually a background
run of "git status" for every submodules goes unnoticed, just
sometimes a submodule is a little too big.
I tried this, but feels like a bit of overkill.
diff --git a/wt-status.c b/wt-status.c
index 8ca59a2..d5bcdf9 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -303,7 +303,10 @@ static void
wt_status_collect_changes_worktree(struct wt_status *s)
init_revisions(&rev, NULL);
setup_revisions(0, NULL, &rev, NULL);
rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
- DIFF_OPT_SET(&rev.diffopt, DIRTY_SUBMODULES);
+ if (s->submodule_summary)
+ DIFF_OPT_SET(&rev.diffopt, DIRTY_SUBMODULES);
+ else
+ DIFF_OPT_SET(&rev.diffopt, IGNORE_SUBMODULES);
if (!s->show_untracked_files)
DIFF_OPT_SET(&rev.diffopt, IGNORE_UNTRACKED_IN_SUBMODULES);
rev.diffopt.format_callback = wt_status_collect_changed_cb;
Am 20.05.2010 16:12, schrieb Alex Riesen:
Maybe because we do a (kind of) gentle status run on submodules
whether the status.SubmoduleSummary set or not.
Yup, because checking a submodule for its dirtiness has to be done
no matter if the summary output is also wanted.
Usually a background
run of "git status" for every submodules goes unnoticed, just
sometimes a submodule is a little too big.
I tried this, but feels like a bit of overkill.
This patch seems to disable submodule output completely for the default
case (when status.SubmoduleSummary is false) and breaks 17 test cases.
So no thumbs up from me ;-)
quoted hunk
diff --git a/wt-status.c b/wt-status.c
index 8ca59a2..d5bcdf9 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -303,7 +303,10 @@ static void
wt_status_collect_changes_worktree(struct wt_status *s)
init_revisions(&rev, NULL);
setup_revisions(0, NULL, &rev, NULL);
rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
- DIFF_OPT_SET(&rev.diffopt, DIRTY_SUBMODULES);
+ if (s->submodule_summary)
+ DIFF_OPT_SET(&rev.diffopt, DIRTY_SUBMODULES);
+ else
+ DIFF_OPT_SET(&rev.diffopt, IGNORE_SUBMODULES);
if (!s->show_untracked_files)
DIFF_OPT_SET(&rev.diffopt, IGNORE_UNTRACKED_IN_SUBMODULES);
rev.diffopt.format_callback = wt_status_collect_changed_cb;
On Thu, May 20, 2010 at 19:45, Jens Lehmann [off-list ref] wrote:
Am 20.05.2010 16:12, schrieb Alex Riesen:
quoted
Maybe because we do a (kind of) gentle status run on submodules
whether the status.SubmoduleSummary set or not.
Yup, because checking a submodule for its dirtiness has to be done
no matter if the summary output is also wanted.
Yeah. Why?
quoted
Usually a background
run of "git status" for every submodules goes unnoticed, just
sometimes a submodule is a little too big.
I tried this, but feels like a bit of overkill.
This patch seems to disable submodule output completely for the default
case (when status.SubmoduleSummary is false) and breaks 17 test cases.
That's why I said it feels like overkill
Am 20.05.2010 21:34, schrieb Alex Riesen:
On Thu, May 20, 2010 at 19:45, Jens Lehmann [off-list ref] wrote:
quoted
Am 20.05.2010 16:12, schrieb Alex Riesen:
quoted
Maybe because we do a (kind of) gentle status run on submodules
whether the status.SubmoduleSummary set or not.
Yup, because checking a submodule for its dirtiness has to be done
no matter if the summary output is also wanted.
Yeah. Why?
Because summary output only describes what commits happened in the
submodule (that operation is rather cheap). The status run is done
to tell what changes in the submodules work tree have occurred since
the last commit there (and for that we have to scan the whole tree).
quoted
quoted
Usually a background
run of "git status" for every submodules goes unnoticed, just
sometimes a submodule is a little too big.
I tried this, but feels like a bit of overkill.
This patch seems to disable submodule output completely for the default
case (when status.SubmoduleSummary is false) and breaks 17 test cases.
That's why I said it feels like overkill
I just wanted to confirm your feeling ;-)