Thread (247 messages) flat view 247 messages, 9 authors, 2021-12-11

Re: [PATCH v10 00/15] Upstreaming the Scalar command

From: Elijah Newren <hidden>
Date: 2021-12-08 18:29:29

I know this was directed to Junio, but I feel like it was my earlier
comment that accidentally opened this can of worms, so if my opinion
helps resolve it at all...

On Wed, Dec 8, 2021 at 3:15 AM Johannes Schindelin
[off-list ref] wrote:
Hi Junio,

On Sun, 5 Dec 2021, Junio C Hamano wrote:
quoted
Elijah Newren [off-list ref] writes:
quoted
From your wording it sounds like the plan might not include moving
these tests over.  Perhaps it doesn't make sense to move them all
over, but since they've caught problems in both Scalar and core Git,
it would be nice to see many of those tests come to Git as well as
part of a future follow on series.
Yeah, we may be initially queuing this without tests for expediency,
but a production code cannot go forever without CI tests to ensure
continued code health.  People make changes in other parts of the
system Scalar may depend on and unknowingly break some assumption
Scalar makes on it.
The Scalar Functional Tests were designed with Azure Repos in mind, i.e.
they specifically verify that the `gvfs-helper` (emulating Partial Clone
using the predecessor of Partial Clone, the GVFS protocol) manages to
access the repositories in the intended way.

I do not know off-hand how entangled the GVFS part is in the test suite,
but from what I recall, every single test starts with cloning a test
repository. From Azure Repos. Using the `gvfs-helper`.

Which means that the `gvfs-helper` would need to be upstreamed and be
maintained in the git.git repository proper.
Ah, sorry, I was remembering this from an earlier cover letter of yours:

"""
But it was realized that many of these key concepts were independent of the
actual VFS and its projection of the working directory. The Scalar project
was created to make that separation, refine the key concepts, and then
extract those features into the new Scalar command.
"""

when I read

"""
One other thing is very interesting about that vfs-with-scalar branch
thicket: it contains a GitHub workflow which will run Scalar's quite
extensive Functional Tests suite. This test suite is quite comprehensive and
caught us a lot of bugs in the past, not only in the Scalar code, but also
core Git.
"""

and I was thinking (despite the branch name) that you had some scalar
+ git (w/o gvfs) tests that were interesting but not planning to
upstream.  I agree that if they're gvfs + scalar + git then they make
sense to keep internal to your work, though I hope that for any bugs
your internal testcases find in git, that you find an upstreamable
testcase to submit.  I believe Stolee has done exactly that in the
past, so just more of that would be good.
Previously I was under the impression that that might be met with grumpy
rejection.

I do realize, though, that clarity of intention has been missing from this
mail thread all around, so let me ask point blank: Junio, do you want me
to include upstreaming `gvfs-helper` in the overall Scalar plan?
I know I'm not Junio, but if my opinion matters, I don't think that
needs to be part of the plan.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help