summaryrefslogtreecommitdiff
path: root/Documentation/technical/scalar.txt
blob: 921cb104c3c4ed556bb8ee25df0f0603b6bf837d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
Scalar
======
 
Scalar is a repository management tool that optimizes Git for use in large
repositories. It accomplishes this by helping users to take advantage of
advanced performance features in Git. Unlike most other Git built-in commands,
Scalar is not executed as a subcommand of 'git'; rather, it is built as a
separate executable containing its own series of subcommands.
 
Background
----------
 
Scalar was originally designed as an add-on to Git and implemented as a .NET
Core application. It was created based on the learnings from the VFS for Git
project (another application aimed at improving the experience of working with
large repositories). As part of its initial implementation, Scalar relied on
custom features in the Microsoft fork of Git that have since been integrated
into core Git:
 
* partial clone,
* commit graphs,
* multi-pack index,
* sparse checkout (cone mode),
* scheduled background maintenance,
* etc
 
With the requisite Git functionality in place and a desire to bring the benefits
of Scalar to the larger Git community, the Scalar application itself was ported
from C# to C and integrated upstream.
 
Features
--------
 
Scalar is comprised of two major pieces of functionality: automatically
configuring built-in Git performance features and managing repository
enlistments.
 
The Git performance features configured by Scalar (see "Background" for
examples) confer substantial performance benefits to large repositories, but are
either too experimental to enable for all of Git yet, or only benefit large
repositories. As new features are introduced, Scalar should be updated
accordingly to incorporate them. This will prevent the tool from becoming stale
while also providing a path for more easily bringing features to the appropriate
users.
 
Enlistments are how Scalar knows which repositories on a user's system should
utilize Scalar-configured features. This allows it to update performance
settings when new ones are added to the tool, as well as centrally manage
repository maintenance. The enlistment structure - a root directory with a
`src/` subdirectory containing the cloned repository itself - is designed to
encourage users to route build outputs outside of the repository to avoid the
performance-limiting overhead of ignoring those files in Git.
 
Design
------
 
Scalar is implemented in C and interacts with Git via a mix of child process
invocations of Git and direct usage of `libgit.a`. Internally, it is structured
much like other built-ins with subcommands (e.g., `git stash`), containing a
`cmd_<subcommand>()` function for each subcommand, routed through a `cmd_main()`
function. Most options are unique to each subcommand, with `scalar` respecting
some "global" `git` options (e.g., `-c` and `-C`).
 
Because `scalar` is not invoked as a Git subcommand (like `git scalar`), it is
built and installed as its own executable in the `bin/` directory, alongside
`git`, `git-gui`, etc.