On 12/09/2014 11:53 PM, Duy Nguyen wrote:
On Tue, Dec 9, 2014 at 5:04 PM, brian m. carlson
<sand...@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 ?
--
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
