Re: [RFC/PATCH 8/8] update-index: make core.untrackedCache a bool

(Sorry I already sent a private reply to Tosten by mistake.)

On Sat, Dec 5, 2015 at 1:44 PM, Torsten Bögershausen [off-list ref] wrote:

On 01.12.15 21:31, Christian Couder wrote:

quoted

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).