Re: git stash takes excessively long when many untracked files present
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:58:25
Possibly related (same subject, not in this thread)
- 2016-06-15 · Re: git stash takes excessively long when many untracked files present · Junio C Hamano <hidden>
- 2016-06-15 · Re: git stash takes excessively long when many untracked files present · Junio C Hamano <hidden>
- 2016-06-15 · Re: git stash takes excessively long when many untracked files present · Josh Triplett <josh@joshtriplett.org>
- 2016-06-15 · Re: git stash takes excessively long when many untracked files present · Junio C Hamano <hidden>
- 2016-06-15 · Re: git stash takes excessively long when many untracked files present · Anders Darander <hidden>
Junio C Hamano [off-list ref] writes:
quoted hunk
diff --git a/dir.c b/dir.c index 910bfcd..02939e2 100644 --- a/dir.c +++ b/dir.c@@ -1183,6 +1183,15 @@ static enum path_treatment treat_one_path(struct dir_struct *dir, cache_name_exists(path->buf, path->len, ignore_case)) return path_none; + /* + * A directory can only contain killed files if the index + * has a path that wants it to be a non-directory. + */ + if ((dir->flags & DIR_COLLECT_KILLED_ONLY) && + (dtype == DT_DIR) && + !cache_name_exists(path->buf, path->len, ignore_case)) + return path_none; +
I think this is wrong.
When we are looking at a directory P in the working tree, there are
three cases:
(1) P exists in the index. Everything inside the directory P in
the working tree needs to go when P is checked out from the
index.
(2) P does not exist in the index, but there is P/Q in the index.
We know P will stay a directory when we check out the contents
of the index, but we do not know yet if there is a directory
P/Q in the working tree to be killed, so we need to recurse.
(3) P does not exist in the index, and there is no P/Q in the index
to require P to be a directory, either. Only in this case, we
know that everything inside P will not be killed without
recursing.
The patch will break with the second case, I think.