Junio C Hamano wrote:

Jonathan Nieder [off-list ref] writes:

quoted

Jonathan Nieder wrote:

quoted

Junio C Hamano wrote:

quoted

quoted

quoted

 Will merge to 'master'.
 cf. [ref]
 source: [ref]

I'd recommend holding off on merging to 'master' for now, until we
figure out what to do about
https://lore.kernel.org/git/YhBCsg2DCEd9FXjE@google.com/ (local). Hopefully that
won't take long.

Since as discussed there this isn't a regression for existing users of
git 'master', I see no reason to hold off on merging to 'master'.

I think I've read on what people said on this topic for the past few
days while I was away.

I do not quite follow the above, though.

Does the logic go like this?

 - Earlier you worried that VFS for Git and similar that have been
   working happily with vanilla Git would break with this series;

 - It turns out that VFS for Git comes with its own version of Git
   that does not have this series;

 - Hence we can do whatever we like to vanilla Git, and it won't
   immediately hurt.

Yes, exactly.

The config knob to tell the sparse logic that it is OK if lstat()
tells us that there appears files that ought to be missing from the
filesystem due to sparse settings would be needed and that is why
you sent an updated proposal patch in separate thread, right?

Shouldn't we iron out the details of that knob and release the topic
with that knob at the same time?

That's fine with me.  I just figured that since this series is already
useful without that knob and the only known affected users are using
"next" anyway, there's no need to delay unaffected users getting the
rest of the improvements while we iron that out.

In practice, fewer people than I'd like run "master" (alas) and the
patch adding the knob looks close to landing anyway, so the difference
is likely mostly moot.

                                  If Microsoft folks already have an
existing knob to tweak the behaviour of sparse checkout to work better
in vfs environment where lstat() lies, and if the necessary adjustment
is wider than just the issue the sparse.expectFilesOutsideOfPatterns
solves, I wonder if we should take the approach to align with their
forked version of Git by matching the name and the behaviour of the
knob somehow.

This is a good point.

I'd expect sparse.expectFilesOutsideOfPatterns to be useful in other
cases that are not a VFS setup, such as having some automation that is
the only writer to a perfectly normal ext4 backed working tree and
uses sparse checkout to tell which files Git should pay attention to
(similar to the old --assume-unchanged use cases but a little easier
to set up).  So I think it would okay for this to exist and be implied
by core.virtualFileystem instead of being solely keyed by that setting
(or in other words I don't think we're painting ourselves into a bad
corner, config naming wise).

Thanks,
Jonathan