Re: [PATCH v3 23/23] untracked cache: guard and disable on system changes
- From
Torsten Bögershausen <tboegi@web.de>
- Date
- Dec 10, 2014, 05:08 UTC
- Message-ID
- <5487D543.7060801@web.de>
- In-Reply-To
- <CACsJy8A5-smRXN0k5TK8uPg4-j-Z83KWLNSO_w-eFivTNB_www@mail.gmail.com>
On 12/09/2014 11:53 PM, Duy Nguyen wrote:
Show 22 quoted lines
> 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 ?