(Sorry I already sent a private reply to Tosten by mistake.) On Sat, Dec 5, 2015 at 1:44 PM, Torsten Bögershausen <tbo...@web.de> wrote: > On 01.12.15 21:31, Christian Couder wrote: >> Most features in Git can be enabled or disabled using a simple >> bool config variable and it would be nice if untracked cache >> behaved the same way. >> >> This makes --[no-|force-]untracked-cache change the value of >> core.untrackedCache in the repo config file, to avoid making >> those options useless and because this avoids the untracked >> cache being disabled by a kernel change or a directory >> change. Of course this breaks some backward compatibility, >> but the simplification and increased useability is worth it. > > Some loose thinking, how the core.untrackedcache and the > command line can work together: > > core.untrackedcache = unset > everything is as today > if --test-untracked-cache is used on command line, > the test is run, additionally the result is stored > in the config variable core.untrackedcache
I don't like storing the result in core.untrackedcache as it means that --test-untracked-cache would not just test. And I agree with Aevar that it's a good thing to be able to completely separate testing and configuring. > core.untrackedcache = true > same as --force-untracked-cache > if --no-untracked-cache is given on command line, > this has higher priority I guess you mean that --no-untracked-cache has priority over "core.untrackedcache = true" without removing this config variable. This means that --no-untracked-cache would only remove the untracked cache (UC) from the index. But what git should then do the next time "git status" is run? Git sees that the index does not contain any UC, but it doesn't know that "git update-index --no-untracked-cache" has just been run. It might be "git config core.untrackedcache true" that has been run last. If "git config core.untrackedcache true" has been run last, it would be logical to add the UC to the index and use it. If "git update-index --no-untracked-cache" has been run last, it would be logical to not add the UC. > core.untrackedcache = false > same as --no-untracked-cache > if --force-untracked-cache is given on command line, > this has higher priority Then the same kind of problem happens as above. There is no clear solution about what "git status" should do when the state of the index conflicts with the value of core.untrackedcache. > Does this support the workflow described by Ævar ? I don't think so. I think that when we set "core.untrackedcache = true" we want the UC to be added to the index and used as much as possible, because we know that our OS/filesystem supports it. This means that using "git update-index --no-untracked-cache" when "core.untrackedcache = true" is set can only have two possible outcomes. It could either just die saying that "core.untrackedcache" is true, or it could just unset "core.untrackedcache" or set it to false (which might mean the same thing). -- 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
