From: Derrick Stolee <derrickstolee@github.com>
To: Victoria Dye <vdye@github.com>,
Victoria Dye via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Cc: Johannes.Schindelin@gmx.de, gitster@pobox.com
Subject: Re: [PATCH 2/2] scalar: convert README.md into a technical design doc
Date: Fri, 15 Jul 2022 12:52:48 -0400 [thread overview]
Message-ID: <b213abee-430b-0365-7e89-558208f3051a@github.com> (raw)
In-Reply-To: <ee9ea998-fb9d-1bf0-635a-e1627c7c1c40@github.com>
On 7/11/2022 7:05 PM, Victoria Dye wrote:
> Derrick Stolee wrote:
>> On 6/29/2022 12:58 PM, Victoria Dye via GitGitGadget wrote:
>>> From: Victoria Dye <vdye@github.com>
>> It can be helpful to include the details of what steps to take to compile and
>> test the 'scalar' executable. That documentation will then be updated when
>> Scalar moves out of contrib/.
>>
>
> As part of the move out of 'contrib/', I was planning on having Scalar built
> and installed the same as any built-in (albeit in 'bin/' - like 'gitk',
> 'git-cvsserver', etc. - rather than 'libexec/git-core'). In that case, there
> won't be any special steps needed to build/install 'scalar', so any
> instructions here would be temporary. I could include those instructions in
> the meantime, but with Scalar incomplete, I'm not sure whether that would be
> valuable.
Ok, I think you don't need those extra steps if the plan is to compile and
test by default. I think we might want to consider the installation steps
and whether or not distributors will want to have an opt-in option for the
scalar binary at that point. Fine to leave that until later.
>> You mention "performant" which makes me think that performance tests are intended
>> to be part of this change. It makes me think it would be interesting to have our
>> existing performance tests create a mode where they compare a "vanilla" Git repo
>> to one registered with Scalar, but otherwise runs the same tests already in the
>> t/perf/ test scripts. This is a wide aside so feel free to ignore me.
>>
>
> This is a really interesting idea! My original plan was to add some basic
> tests around the operations 'scalar' should (directly or indirectly) speed
> up. I think I'll still need to do that anyway (e.g., for things like 'scalar
> clone' vs 'git clone'), but I'll also try to find a (repeatable) way to
> compare standard repo vs. Scalar enlistment performance in the existing perf
> tests.
It's tricky since our performance tests don't clone across a network boundary,
but maybe we could create a new class of tests to operate against a Git server
specified by the tester. Definitely out of scope for this series.
Thanks,
-Stolee
next prev parent reply other threads:[~2022-07-15 16:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-29 16:58 [PATCH 0/2] [RFC] scalar: prepare documentation for future work Victoria Dye via GitGitGadget
2022-06-29 16:58 ` [PATCH 1/2] scalar: reword command documentation to clarify purpose Victoria Dye via GitGitGadget
2022-06-29 16:58 ` [PATCH 2/2] scalar: convert README.md into a technical design doc Victoria Dye via GitGitGadget
2022-06-29 17:58 ` Derrick Stolee
2022-07-11 23:05 ` Victoria Dye
2022-07-15 16:52 ` Derrick Stolee [this message]
2022-06-29 17:41 ` [PATCH 0/2] [RFC] scalar: prepare documentation for future work Derrick Stolee
2022-06-29 21:50 ` Johannes Schindelin
2022-07-12 0:06 ` [PATCH v2 0/2] " Victoria Dye via GitGitGadget
2022-07-12 0:06 ` [PATCH v2 1/2] scalar: reword command documentation to clarify purpose Victoria Dye via GitGitGadget
2022-07-12 0:06 ` [PATCH v2 2/2] scalar: convert README.md into a technical design doc Victoria Dye via GitGitGadget
2022-07-15 16:53 ` [PATCH v2 0/2] scalar: prepare documentation for future work Derrick Stolee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b213abee-430b-0365-7e89-558208f3051a@github.com \
--to=derrickstolee@github.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=vdye@github.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.