From: Torsten Bögershausen Date: Wed, 10 Dec 2014 05:08:19 GMT Subject: Re: [PATCH v3 23/23] untracked cache: guard and disable on system changes Message-ID: <5487D543.7060801@web.de> In-Reply-To: On 12/09/2014 11:53 PM, Duy Nguyen wrote: > On Tue, Dec 9, 2014 at 5:04 PM, brian m. carlson > 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 ?