On Tue, Dec 15, 2015 at 4:34 PM, Christian Couder <christian.cou...@gmail.com> wrote: > On Mon, Dec 14, 2015 at 10:30 PM, Junio C Hamano <gits...@pobox.com> wrote: >> Junio C Hamano <gits...@pobox.com> writes: >> >> The primary reason why I do not like your "configuration decides" is >> it will be a huge source of confusions and bugs. Imagine what >> should happen in this sequence, and when should a stale cached >> information be discarded? >> >> - the configuration is set to 'yes'. >> - the index is updated and written by various commands. >> - more work is done in the working tree without updating the index. >> - the configuration is set to 'no'. >> - more work is done in the working tree without updating the index. >> - the configuration is set to 'yes'. >> - more work is done in the working tree without updating the index. >> - somebody asks "what untracked paths are there?" > > As far as I understand the UC just stores the mtime of the directories > in the working tree to avoid the need of lstat'ing all the files in > the directories. > > When somebody asks "what untracked paths are there", if the UC has not > been discarded when the configuration was set to no, then git will > just ask for the mtimes of the directories in the working tree and > compare them with what is in the UC. > > I don't see how it can create confusion and bugs, as the work done in > the working tree should anyway have changed the mtime of the > directories where work has been done.
Any operation that can add or remove an entry from the index may lead to UC update. For example, if file "foo" is tracked, then the user does "git rm --cached foo", "foo" may become either untracked or ignored. So if you disable UC while doing this removal, then re-enable UC again, "git-status" may show incorrect output. So, as long as UC extension exists in the index, it must be updated, or it may become outdated and useless. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
