On Tue, Dec 15, 2015 at 11:02 AM, Duy Nguyen <pclo...@gmail.com> wrote: > 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.
When UC is disabled, it is removed from the index, and when it is (re-)enabled, it is recreated, so I don't think that your example applies to the code in this patch. Thanks anyway for this insight, Christian. -- 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
