RE: [PATCH v6 0/6] fsmonitor: option to allow fsmonitor to run against network-mounted repos
Show 63 quoted lines
> -----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