Message ID | pull.1326.v6.git.1663100858.gitgitgadget@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | fsmonitor: option to allow fsmonitor to run against network-mounted repos | expand |
On 9/13/22 4:27 PM, Eric DeCosta via GitGitGadget wrote: > Follow-on to the work done to allow Windows to work against network-mounted > repos for macOS. > > Have macOS take advantage of the same configuration option, > 'fsmonitor.allowRemote' that was introduced for Windows. Setting this option > to true will override the default behavior (erroring-out) when a > network-mounted repo is detected by fsmonitor. > > The added wrinkle being that the Unix domain socket (UDS) file used for IPC > cannot be created in a network location; instead $HOME is used if the > default location is on the network. The user may, optionally, set the > 'fsmonitor.socketDir' configuration option to a valid, local directory if > $HOME itself is on the network or is simply not the desired location for the > UDS file. > > An additional issue is that for mount points in the root directory, FSEvents > does not report a path that matches the worktree directory due to the > introduction of 'synthetic firmlinks'. fsmonitor must map the FSEvents paths > to the worktree directory by interrogating the root filesystem for synthetic > firmlinks and using that information to translate the path. > > v6 differs from v5: > > * incorporates earlier, Windows-specific changes that have not made it back > yet to the master branch > * incorporates code review feedback > * adds documentation for 'fsmonitor.allowRemote' and 'fsmonitor.socketDir' > > v5 differs significantly from earlier versions: > > * redesign of handling 'fsmonitor.allowRemote' and 'fsmonitor.socketDir' > such that these options are no longer added to the settings data > structure but are rather read from config at point of use > * refactoring of code for handling platform-specific file system checks via > a common interface to avoid platform #ifdef in IPC code and be in-model > with other platform-specific fsmonitor code > * dealing with 'synthetic firmlinks' on macOS > I've looked at v5 and v6 and I like the direction this is heading, so I'll mark this LGTM. (I'm still traveling back from Git Merge, so I haven't had time to test it out, but I think we should proceed with it.) Thanks for you patience and attention to detail on this! Jeff
> -----Original Message----- > From: Jeff Hostetler <git@jeffhostetler.com> > Sent: Friday, September 16, 2022 1:59 PM > To: Eric DeCosta via GitGitGadget <gitgitgadget@gmail.com>; > git@vger.kernel.org > Cc: Eric Sunshine <sunshine@sunshineco.com>; Torsten Bögershausen > <tboegi@web.de>; Ævar Arnfjörð Bjarmason <avarab@gmail.com>; Ramsay > Jones <ramsay@ramsayjones.plus.com>; Johannes Schindelin > <Johannes.Schindelin@gmx.de>; Eric DeCosta <edecosta@mathworks.com> > Subject: Re: [PATCH v6 0/6] fsmonitor: option to allow fsmonitor to run > against network-mounted repos > > > > On 9/13/22 4:27 PM, Eric DeCosta via GitGitGadget wrote: > > Follow-on to the work done to allow Windows to work against > > network-mounted repos for macOS. > > > > Have macOS take advantage of the same configuration option, > > 'fsmonitor.allowRemote' that was introduced for Windows. Setting this > > option to true will override the default behavior (erroring-out) when > > a network-mounted repo is detected by fsmonitor. > > > > The added wrinkle being that the Unix domain socket (UDS) file used > > for IPC cannot be created in a network location; instead $HOME is used > > if the default location is on the network. The user may, optionally, > > set the 'fsmonitor.socketDir' configuration option to a valid, local > > directory if $HOME itself is on the network or is simply not the > > desired location for the UDS file. > > > > An additional issue is that for mount points in the root directory, > > FSEvents does not report a path that matches the worktree directory > > due to the introduction of 'synthetic firmlinks'. fsmonitor must map > > the FSEvents paths to the worktree directory by interrogating the root > > filesystem for synthetic firmlinks and using that information to translate the > path. > > > > v6 differs from v5: > > > > * incorporates earlier, Windows-specific changes that have not made it > back > > yet to the master branch > > * incorporates code review feedback > > * adds documentation for 'fsmonitor.allowRemote' and > 'fsmonitor.socketDir' > > > > v5 differs significantly from earlier versions: > > > > * redesign of handling 'fsmonitor.allowRemote' and 'fsmonitor.socketDir' > > such that these options are no longer added to the settings data > > structure but are rather read from config at point of use > > * refactoring of code for handling platform-specific file system checks via > > a common interface to avoid platform #ifdef in IPC code and be in-model > > with other platform-specific fsmonitor code > > * dealing with 'synthetic firmlinks' on macOS > > > > I've looked at v5 and v6 and I like the direction this is heading, so I'll mark this > LGTM. (I'm still traveling back from Git Merge, so I haven't had time to test it > out, but I think we should proceed with it.) > > Thanks for you patience and attention to detail on this! > Jeff Great! I just created v7 with some small updates based on Junio's feedback. I think this landed in a pretty good place. I don't know that the plans are for fsmonitor on Linux, but I've already started tinkering around with an inotify-based implementation for that platform. The devil is in the details, of course, but it looks fairly straight-forward. -Eric