Re: [PATCH v3 23/23] untracked cache: guard and disable on system changes

["Torsten Bögershausen" <tboegi@web.de>]

On 12/09/2014 11:53 PM, Duy Nguyen wrote:
> On Tue, Dec 9, 2014 at 5:04 PM, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
>> On Mon, Dec 08, 2014 at 09:05:07PM +0700, Nguyễn Thái Ngọc Duy wrote:
>>> If the user enables untracked cache, then
>>>
>>>   - move worktree to an unsupported filesystem
>>>   - or simply upgrade OS
>>>   - or move the whole (portable) disk from one machine to another
>>>   - or access a shared fs from another machine
>>>
>>> there's no guarantee that untracked cache can still function properly.
>>> Record the worktree location and OS footprint in the cache. If it
>>> changes, err on the safe side and disable the cache. The user can
>>> 'update-index --untracked-cache' again to make sure all conditions are
>>> met.
>> My use case for untracked cache is where I have one machine with a
>> repository and which is also mounted via sshfs on another machine.  It
>> looks like this will disable the cache every time I change the machine I
>> access it on.  Would you be willing to accept a patch for a configuration
>> option to disable this?
> Torsten also does not like this patch. Maybe I'm just too paranoid.
> Maybe we can drop this patch.
That opens another question:
How flexible/extensible/self-describing is the format of the UNTR 
extension ?
If we drop the OS name & root dir check because it disallows network use,
but later add a better method to verify that the underlying chain
local OS - network - remote OS-remote FS is OK,
do we need to change the file format of UNTR ?
If yes, can old clients read the new format and vice versa?
Do we need a version information of some kind, or does the
old client skip unknown entries like we do with extensions in the index ?