git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/2] scalar: convert README.md into a technical design doc

From
Derrick Stolee <derrickstolee@github.com>
Date
Jul 15, 2022, 16:52 UTC
Message-ID
<b213abee-430b-0365-7e89-558208f3051a@github.com>
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>
Show 12 quoted lines
>> 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.

Show 13 quoted lines
>> 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

Previous: Victoria DyeNext: Derrick Stolee
Message 6 of 12 in “[RFC] scalar: prepare documentation for future work”
  1. 0/2 [RFC] scalar: prepare documentation for future workVictoria Dye via GitGitGadget, Jun 29, 2022
  2. 1/2 scalar: reword command documentation to clarify purposeVictoria Dye via GitGitGadget, Jun 29, 2022
  3. 2/2 scalar: convert README.md into a technical design docVictoria Dye via GitGitGadget, Jun 29, 2022
  4. Derrick StoleeJun 29, 2022
  5. Victoria DyeJul 11, 2022
  6. Derrick StoleeJul 15, 2022
  7. Derrick StoleeJun 29, 2022
  8. Johannes SchindelinJun 29, 2022
  9. 0/2 scalar: prepare documentation for future workVictoria Dye via GitGitGadget, Jul 12, 2022
  10. 1/2 scalar: reword command documentation to clarify purposeVictoria Dye via GitGitGadget, Jul 12, 2022
  11. 2/2 scalar: convert README.md into a technical design docVictoria Dye via GitGitGadget, Jul 12, 2022
  12. Derrick StoleeJul 15, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.