scalar: create a rudimentary executable
The idea of Scalar (https://github.com/microsoft/scalar), and before
that, of VFS for Git, has always been to prove that Git _can_ scale, and
to upstream whatever strategies have been demonstrated to help.
With this patch, we start the journey from that C# project to move what
is left to Git's own `contrib/` directory, reimplementing it in pure C,
with the intention to facilitate integrating the functionality into core
Git all while maintaining backwards-compatibility for existing Scalar
users (which will be much easier when both live in the same worktree).
It has always been the plan to contribute all of the proven strategies
back to core Git.
For example, while the virtual filesystem provided by VFS for Git helped
the team developing the Windows operating system to move onto Git, while
trying to upstream it we realized that it cannot be done: getting the
virtual filesystem to work (which we only managed to implement fully on
Windows, but not on, say, macOS or Linux), and the required server-side
support for the GVFS protocol, made this not quite feasible.
The Scalar project learned from that and tackled the problem with
different tactics: instead of pretending to Git that the working
directory is fully populated, it _specifically_ teaches Git about
partial clone (which is based on VFS for Git's cache server), about
sparse checkout (which VFS for Git tried to do transparently, in the
file system layer), and regularly runs maintenance tasks to keep the
repository in a healthy state.
With partial clone, sparse checkout and `git maintenance` having been
upstreamed, there is little left that `scalar.exe` does which `git.exe`
cannot do. One such thing is that `scalar clone <url>` will
automatically set up a partial, sparse clone, and configure
known-helpful settings from the start.
So let's bring this convenience into Git's tree.
The idea here is that you can (optionally) build Scalar via
make -C contrib/scalar/
This will build the `scalar` executable and put it into the
contrib/scalar/ subdirectory.
The slightly awkward addition of the `contrib/scalar/*` bits to the
top-level `Makefile` are actually really required: we want to link to
`libgit.a`, which means that we will need to use the very same `CFLAGS`
and `LDFLAGS` as the rest of Git.
An early development version of this patch tried to replicate all the
conditional code in `contrib/scalar/Makefile` (e.g. `NO_POLL`) just like
`contrib/svn-fe/Makefile` used to do before it was retired. It turned
out to be quite the whack-a-mole game: the SHA-1-related flags, the
flags enabling/disabling `compat/poll/`, `compat/regex/`,
`compat/win32mmap.c` & friends depending on the current platform... To
put it mildly: it was a major mess.
Instead, this patch makes minimal changes to the top-level `Makefile` so
that the bits in `contrib/scalar/` can be compiled and linked, and
adds a `contrib/scalar/Makefile` that uses the top-level `Makefile` in a
most minimal way to do the actual compiling.
Note: With this commit, we only establish the infrastructure, no
Scalar functionality is implemented yet; We will do that incrementally
over the next few commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03 13:34:16 +00:00
|
|
|
/*
|
|
|
|
* The Scalar command-line interface.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "cache.h"
|
|
|
|
#include "gettext.h"
|
|
|
|
#include "parse-options.h"
|
2021-12-03 13:34:19 +00:00
|
|
|
#include "config.h"
|
|
|
|
#include "run-command.h"
|
2022-08-18 21:40:51 +00:00
|
|
|
#include "simple-ipc.h"
|
|
|
|
#include "fsmonitor-ipc.h"
|
|
|
|
#include "fsmonitor-settings.h"
|
2021-12-03 13:34:23 +00:00
|
|
|
#include "refs.h"
|
2021-12-03 13:34:28 +00:00
|
|
|
#include "dir.h"
|
|
|
|
#include "packfile.h"
|
2021-12-03 13:34:29 +00:00
|
|
|
#include "help.h"
|
2021-12-03 13:34:19 +00:00
|
|
|
|
|
|
|
static void setup_enlistment_directory(int argc, const char **argv,
|
|
|
|
const char * const *usagestr,
|
|
|
|
const struct option *options,
|
|
|
|
struct strbuf *enlistment_root)
|
|
|
|
{
|
|
|
|
struct strbuf path = STRBUF_INIT;
|
scalar: constrain enlistment search
Make the search for repository and enlistment root in
'setup_enlistment_directory()' more constrained to simplify behavior and
adhere to 'GIT_CEILING_DIRECTORIES'.
Previously, 'setup_enlistment_directory()' would check whether the provided
path (or current working directory) '<dir>' or its subdirectory '<dir>/src'
was a repository root. If not, the process would repeat on the parent of
'<dir>' until the repository was found or it reached the root of the
filesystem. This meant that a user could specify a path *anywhere* inside an
enlistment (including paths not in the repository contained within the
enlistment) and it would be found.
The downside to this process is that the search would not account for
'GIT_CEILING_DIRECTORIES', so the upward search could result in modifying
repository contents past 'GIT_CEILING_DIRECTORIES'. Similarly, operations
like 'scalar delete' could end up unintentionally deleting the parent of a
repo if its root was named 'src'.
To make this 'setup_enlistment_directory()' both adhere to
'GIT_CEILING_DIRECTORIES' and avoid unwanted deletions, the search for an
enlistment directory is simplified to:
- if '<dir>/src' is a repository root, '<dir>' is the enlistment root
- if '<dir>' is either the repository root or contained within a repository,
the repository root is the enlistment root
Now, only 'setup_git_directory()' (called by 'setup_enlistment_directory()')
searches upwards from the 'scalar' specified path, enforcing
'GIT_CEILING_DIRECTORIES' in the process. Additionally, 'scalar delete
<dir>/src' will not delete '<dir>' (if users would like to delete it, they
can still specify the enlistment root with 'scalar delete <dir>'). This is
true of any 'scalar' operation; users can invoke 'scalar' on the enlistment
root, but paths must otherwise be inside the repository to be valid.
To help clarify the updated behavior, new tests are added to
't9099-scalar.sh'.
Finally, this change leaves 'strbuf_parent_directory()' with only a single,
WIN32-specific caller in 'delete_enlistment()'. Rather than wrap
'strbuf_parent_directory()' in '#ifdef WIN32' to avoid the "unused function"
compiler error, move the contents of 'strbuf_parent_directory()' into
'delete_enlistment()' and remove the function.
Helped-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-18 21:40:46 +00:00
|
|
|
int enlistment_is_repo_parent = 0;
|
|
|
|
size_t len;
|
2021-12-03 13:34:19 +00:00
|
|
|
|
|
|
|
if (startup_info->have_repository)
|
|
|
|
BUG("gitdir already set up?!?");
|
|
|
|
|
|
|
|
if (argc > 1)
|
|
|
|
usage_with_options(usagestr, options);
|
|
|
|
|
|
|
|
/* find the worktree, determine its corresponding root */
|
2022-05-28 23:11:14 +00:00
|
|
|
if (argc == 1) {
|
2021-12-03 13:34:19 +00:00
|
|
|
strbuf_add_absolute_path(&path, argv[0]);
|
2022-05-28 23:11:14 +00:00
|
|
|
if (!is_directory(path.buf))
|
|
|
|
die(_("'%s' does not exist"), path.buf);
|
scalar: constrain enlistment search
Make the search for repository and enlistment root in
'setup_enlistment_directory()' more constrained to simplify behavior and
adhere to 'GIT_CEILING_DIRECTORIES'.
Previously, 'setup_enlistment_directory()' would check whether the provided
path (or current working directory) '<dir>' or its subdirectory '<dir>/src'
was a repository root. If not, the process would repeat on the parent of
'<dir>' until the repository was found or it reached the root of the
filesystem. This meant that a user could specify a path *anywhere* inside an
enlistment (including paths not in the repository contained within the
enlistment) and it would be found.
The downside to this process is that the search would not account for
'GIT_CEILING_DIRECTORIES', so the upward search could result in modifying
repository contents past 'GIT_CEILING_DIRECTORIES'. Similarly, operations
like 'scalar delete' could end up unintentionally deleting the parent of a
repo if its root was named 'src'.
To make this 'setup_enlistment_directory()' both adhere to
'GIT_CEILING_DIRECTORIES' and avoid unwanted deletions, the search for an
enlistment directory is simplified to:
- if '<dir>/src' is a repository root, '<dir>' is the enlistment root
- if '<dir>' is either the repository root or contained within a repository,
the repository root is the enlistment root
Now, only 'setup_git_directory()' (called by 'setup_enlistment_directory()')
searches upwards from the 'scalar' specified path, enforcing
'GIT_CEILING_DIRECTORIES' in the process. Additionally, 'scalar delete
<dir>/src' will not delete '<dir>' (if users would like to delete it, they
can still specify the enlistment root with 'scalar delete <dir>'). This is
true of any 'scalar' operation; users can invoke 'scalar' on the enlistment
root, but paths must otherwise be inside the repository to be valid.
To help clarify the updated behavior, new tests are added to
't9099-scalar.sh'.
Finally, this change leaves 'strbuf_parent_directory()' with only a single,
WIN32-specific caller in 'delete_enlistment()'. Rather than wrap
'strbuf_parent_directory()' in '#ifdef WIN32' to avoid the "unused function"
compiler error, move the contents of 'strbuf_parent_directory()' into
'delete_enlistment()' and remove the function.
Helped-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-18 21:40:46 +00:00
|
|
|
if (chdir(path.buf) < 0)
|
|
|
|
die_errno(_("could not switch to '%s'"), path.buf);
|
2022-05-28 23:11:14 +00:00
|
|
|
} else if (strbuf_getcwd(&path) < 0)
|
2021-12-03 13:34:19 +00:00
|
|
|
die(_("need a working directory"));
|
|
|
|
|
|
|
|
strbuf_trim_trailing_dir_sep(&path);
|
|
|
|
|
scalar: constrain enlistment search
Make the search for repository and enlistment root in
'setup_enlistment_directory()' more constrained to simplify behavior and
adhere to 'GIT_CEILING_DIRECTORIES'.
Previously, 'setup_enlistment_directory()' would check whether the provided
path (or current working directory) '<dir>' or its subdirectory '<dir>/src'
was a repository root. If not, the process would repeat on the parent of
'<dir>' until the repository was found or it reached the root of the
filesystem. This meant that a user could specify a path *anywhere* inside an
enlistment (including paths not in the repository contained within the
enlistment) and it would be found.
The downside to this process is that the search would not account for
'GIT_CEILING_DIRECTORIES', so the upward search could result in modifying
repository contents past 'GIT_CEILING_DIRECTORIES'. Similarly, operations
like 'scalar delete' could end up unintentionally deleting the parent of a
repo if its root was named 'src'.
To make this 'setup_enlistment_directory()' both adhere to
'GIT_CEILING_DIRECTORIES' and avoid unwanted deletions, the search for an
enlistment directory is simplified to:
- if '<dir>/src' is a repository root, '<dir>' is the enlistment root
- if '<dir>' is either the repository root or contained within a repository,
the repository root is the enlistment root
Now, only 'setup_git_directory()' (called by 'setup_enlistment_directory()')
searches upwards from the 'scalar' specified path, enforcing
'GIT_CEILING_DIRECTORIES' in the process. Additionally, 'scalar delete
<dir>/src' will not delete '<dir>' (if users would like to delete it, they
can still specify the enlistment root with 'scalar delete <dir>'). This is
true of any 'scalar' operation; users can invoke 'scalar' on the enlistment
root, but paths must otherwise be inside the repository to be valid.
To help clarify the updated behavior, new tests are added to
't9099-scalar.sh'.
Finally, this change leaves 'strbuf_parent_directory()' with only a single,
WIN32-specific caller in 'delete_enlistment()'. Rather than wrap
'strbuf_parent_directory()' in '#ifdef WIN32' to avoid the "unused function"
compiler error, move the contents of 'strbuf_parent_directory()' into
'delete_enlistment()' and remove the function.
Helped-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-18 21:40:46 +00:00
|
|
|
/* check if currently in enlistment root with src/ workdir */
|
|
|
|
len = path.len;
|
|
|
|
strbuf_addstr(&path, "/src");
|
|
|
|
if (is_nonbare_repository_dir(&path)) {
|
|
|
|
enlistment_is_repo_parent = 1;
|
|
|
|
if (chdir(path.buf) < 0)
|
|
|
|
die_errno(_("could not switch to '%s'"), path.buf);
|
|
|
|
}
|
|
|
|
strbuf_setlen(&path, len);
|
2021-12-03 13:34:19 +00:00
|
|
|
|
scalar: constrain enlistment search
Make the search for repository and enlistment root in
'setup_enlistment_directory()' more constrained to simplify behavior and
adhere to 'GIT_CEILING_DIRECTORIES'.
Previously, 'setup_enlistment_directory()' would check whether the provided
path (or current working directory) '<dir>' or its subdirectory '<dir>/src'
was a repository root. If not, the process would repeat on the parent of
'<dir>' until the repository was found or it reached the root of the
filesystem. This meant that a user could specify a path *anywhere* inside an
enlistment (including paths not in the repository contained within the
enlistment) and it would be found.
The downside to this process is that the search would not account for
'GIT_CEILING_DIRECTORIES', so the upward search could result in modifying
repository contents past 'GIT_CEILING_DIRECTORIES'. Similarly, operations
like 'scalar delete' could end up unintentionally deleting the parent of a
repo if its root was named 'src'.
To make this 'setup_enlistment_directory()' both adhere to
'GIT_CEILING_DIRECTORIES' and avoid unwanted deletions, the search for an
enlistment directory is simplified to:
- if '<dir>/src' is a repository root, '<dir>' is the enlistment root
- if '<dir>' is either the repository root or contained within a repository,
the repository root is the enlistment root
Now, only 'setup_git_directory()' (called by 'setup_enlistment_directory()')
searches upwards from the 'scalar' specified path, enforcing
'GIT_CEILING_DIRECTORIES' in the process. Additionally, 'scalar delete
<dir>/src' will not delete '<dir>' (if users would like to delete it, they
can still specify the enlistment root with 'scalar delete <dir>'). This is
true of any 'scalar' operation; users can invoke 'scalar' on the enlistment
root, but paths must otherwise be inside the repository to be valid.
To help clarify the updated behavior, new tests are added to
't9099-scalar.sh'.
Finally, this change leaves 'strbuf_parent_directory()' with only a single,
WIN32-specific caller in 'delete_enlistment()'. Rather than wrap
'strbuf_parent_directory()' in '#ifdef WIN32' to avoid the "unused function"
compiler error, move the contents of 'strbuf_parent_directory()' into
'delete_enlistment()' and remove the function.
Helped-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-18 21:40:46 +00:00
|
|
|
setup_git_directory();
|
2021-12-03 13:34:19 +00:00
|
|
|
|
scalar: constrain enlistment search
Make the search for repository and enlistment root in
'setup_enlistment_directory()' more constrained to simplify behavior and
adhere to 'GIT_CEILING_DIRECTORIES'.
Previously, 'setup_enlistment_directory()' would check whether the provided
path (or current working directory) '<dir>' or its subdirectory '<dir>/src'
was a repository root. If not, the process would repeat on the parent of
'<dir>' until the repository was found or it reached the root of the
filesystem. This meant that a user could specify a path *anywhere* inside an
enlistment (including paths not in the repository contained within the
enlistment) and it would be found.
The downside to this process is that the search would not account for
'GIT_CEILING_DIRECTORIES', so the upward search could result in modifying
repository contents past 'GIT_CEILING_DIRECTORIES'. Similarly, operations
like 'scalar delete' could end up unintentionally deleting the parent of a
repo if its root was named 'src'.
To make this 'setup_enlistment_directory()' both adhere to
'GIT_CEILING_DIRECTORIES' and avoid unwanted deletions, the search for an
enlistment directory is simplified to:
- if '<dir>/src' is a repository root, '<dir>' is the enlistment root
- if '<dir>' is either the repository root or contained within a repository,
the repository root is the enlistment root
Now, only 'setup_git_directory()' (called by 'setup_enlistment_directory()')
searches upwards from the 'scalar' specified path, enforcing
'GIT_CEILING_DIRECTORIES' in the process. Additionally, 'scalar delete
<dir>/src' will not delete '<dir>' (if users would like to delete it, they
can still specify the enlistment root with 'scalar delete <dir>'). This is
true of any 'scalar' operation; users can invoke 'scalar' on the enlistment
root, but paths must otherwise be inside the repository to be valid.
To help clarify the updated behavior, new tests are added to
't9099-scalar.sh'.
Finally, this change leaves 'strbuf_parent_directory()' with only a single,
WIN32-specific caller in 'delete_enlistment()'. Rather than wrap
'strbuf_parent_directory()' in '#ifdef WIN32' to avoid the "unused function"
compiler error, move the contents of 'strbuf_parent_directory()' into
'delete_enlistment()' and remove the function.
Helped-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-18 21:40:46 +00:00
|
|
|
if (!the_repository->worktree)
|
|
|
|
die(_("Scalar enlistments require a worktree"));
|
2021-12-03 13:34:19 +00:00
|
|
|
|
scalar: constrain enlistment search
Make the search for repository and enlistment root in
'setup_enlistment_directory()' more constrained to simplify behavior and
adhere to 'GIT_CEILING_DIRECTORIES'.
Previously, 'setup_enlistment_directory()' would check whether the provided
path (or current working directory) '<dir>' or its subdirectory '<dir>/src'
was a repository root. If not, the process would repeat on the parent of
'<dir>' until the repository was found or it reached the root of the
filesystem. This meant that a user could specify a path *anywhere* inside an
enlistment (including paths not in the repository contained within the
enlistment) and it would be found.
The downside to this process is that the search would not account for
'GIT_CEILING_DIRECTORIES', so the upward search could result in modifying
repository contents past 'GIT_CEILING_DIRECTORIES'. Similarly, operations
like 'scalar delete' could end up unintentionally deleting the parent of a
repo if its root was named 'src'.
To make this 'setup_enlistment_directory()' both adhere to
'GIT_CEILING_DIRECTORIES' and avoid unwanted deletions, the search for an
enlistment directory is simplified to:
- if '<dir>/src' is a repository root, '<dir>' is the enlistment root
- if '<dir>' is either the repository root or contained within a repository,
the repository root is the enlistment root
Now, only 'setup_git_directory()' (called by 'setup_enlistment_directory()')
searches upwards from the 'scalar' specified path, enforcing
'GIT_CEILING_DIRECTORIES' in the process. Additionally, 'scalar delete
<dir>/src' will not delete '<dir>' (if users would like to delete it, they
can still specify the enlistment root with 'scalar delete <dir>'). This is
true of any 'scalar' operation; users can invoke 'scalar' on the enlistment
root, but paths must otherwise be inside the repository to be valid.
To help clarify the updated behavior, new tests are added to
't9099-scalar.sh'.
Finally, this change leaves 'strbuf_parent_directory()' with only a single,
WIN32-specific caller in 'delete_enlistment()'. Rather than wrap
'strbuf_parent_directory()' in '#ifdef WIN32' to avoid the "unused function"
compiler error, move the contents of 'strbuf_parent_directory()' into
'delete_enlistment()' and remove the function.
Helped-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-18 21:40:46 +00:00
|
|
|
if (enlistment_root) {
|
|
|
|
if (enlistment_is_repo_parent)
|
|
|
|
strbuf_addbuf(enlistment_root, &path);
|
|
|
|
else
|
|
|
|
strbuf_addstr(enlistment_root, the_repository->worktree);
|
|
|
|
}
|
2021-12-03 13:34:19 +00:00
|
|
|
|
|
|
|
strbuf_release(&path);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int run_git(const char *arg, ...)
|
|
|
|
{
|
|
|
|
struct strvec argv = STRVEC_INIT;
|
|
|
|
va_list args;
|
|
|
|
const char *p;
|
|
|
|
int res;
|
|
|
|
|
|
|
|
va_start(args, arg);
|
|
|
|
strvec_push(&argv, arg);
|
|
|
|
while ((p = va_arg(args, const char *)))
|
|
|
|
strvec_push(&argv, p);
|
|
|
|
va_end(args);
|
|
|
|
|
|
|
|
res = run_command_v_opt(argv.v, RUN_GIT_CMD);
|
|
|
|
|
|
|
|
strvec_clear(&argv);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2022-08-18 21:40:50 +00:00
|
|
|
struct scalar_config {
|
|
|
|
const char *key;
|
|
|
|
const char *value;
|
|
|
|
int overwrite_on_reconfigure;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int set_scalar_config(const struct scalar_config *config, int reconfigure)
|
|
|
|
{
|
|
|
|
char *value = NULL;
|
|
|
|
int res;
|
|
|
|
|
|
|
|
if ((reconfigure && config->overwrite_on_reconfigure) ||
|
|
|
|
git_config_get_string(config->key, &value)) {
|
|
|
|
trace2_data_string("scalar", the_repository, config->key, "created");
|
|
|
|
res = git_config_set_gently(config->key, config->value);
|
|
|
|
} else {
|
|
|
|
trace2_data_string("scalar", the_repository, config->key, "exists");
|
|
|
|
res = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
free(value);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2022-08-18 21:40:51 +00:00
|
|
|
static int have_fsmonitor_support(void)
|
|
|
|
{
|
|
|
|
return fsmonitor_ipc__is_supported() &&
|
|
|
|
fsm_settings__get_reason(the_repository) == FSMONITOR_REASON_OK;
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:26 +00:00
|
|
|
static int set_recommended_config(int reconfigure)
|
2021-12-03 13:34:19 +00:00
|
|
|
{
|
2022-08-18 21:40:50 +00:00
|
|
|
struct scalar_config config[] = {
|
2021-12-03 13:34:26 +00:00
|
|
|
/* Required */
|
|
|
|
{ "am.keepCR", "true", 1 },
|
|
|
|
{ "core.FSCache", "true", 1 },
|
|
|
|
{ "core.multiPackIndex", "true", 1 },
|
|
|
|
{ "core.preloadIndex", "true", 1 },
|
2021-12-03 13:34:19 +00:00
|
|
|
#ifndef WIN32
|
2021-12-03 13:34:26 +00:00
|
|
|
{ "core.untrackedCache", "true", 1 },
|
2021-12-03 13:34:19 +00:00
|
|
|
#else
|
|
|
|
/*
|
|
|
|
* Unfortunately, Scalar's Functional Tests demonstrated
|
|
|
|
* that the untracked cache feature is unreliable on Windows
|
|
|
|
* (which is a bummer because that platform would benefit the
|
|
|
|
* most from it). For some reason, freshly created files seem
|
|
|
|
* not to update the directory's `lastModified` time
|
|
|
|
* immediately, but the untracked cache would need to rely on
|
|
|
|
* that.
|
|
|
|
*
|
|
|
|
* Therefore, with a sad heart, we disable this very useful
|
|
|
|
* feature on Windows.
|
|
|
|
*/
|
2021-12-03 13:34:26 +00:00
|
|
|
{ "core.untrackedCache", "false", 1 },
|
2021-12-03 13:34:19 +00:00
|
|
|
#endif
|
2021-12-03 13:34:26 +00:00
|
|
|
{ "core.logAllRefUpdates", "true", 1 },
|
|
|
|
{ "credential.https://dev.azure.com.useHttpPath", "true", 1 },
|
|
|
|
{ "credential.validate", "false", 1 }, /* GCM4W-only */
|
|
|
|
{ "gc.auto", "0", 1 },
|
|
|
|
{ "gui.GCWarning", "false", 1 },
|
|
|
|
{ "index.threads", "true", 1 },
|
|
|
|
{ "index.version", "4", 1 },
|
|
|
|
{ "merge.stat", "false", 1 },
|
|
|
|
{ "merge.renames", "true", 1 },
|
|
|
|
{ "pack.useBitmaps", "false", 1 },
|
|
|
|
{ "pack.useSparse", "true", 1 },
|
|
|
|
{ "receive.autoGC", "false", 1 },
|
|
|
|
{ "feature.manyFiles", "false", 1 },
|
|
|
|
{ "feature.experimental", "false", 1 },
|
|
|
|
{ "fetch.unpackLimit", "1", 1 },
|
|
|
|
{ "fetch.writeCommitGraph", "false", 1 },
|
2021-12-03 13:34:19 +00:00
|
|
|
#ifdef WIN32
|
2021-12-03 13:34:26 +00:00
|
|
|
{ "http.sslBackend", "schannel", 1 },
|
2021-12-03 13:34:19 +00:00
|
|
|
#endif
|
2021-12-03 13:34:26 +00:00
|
|
|
/* Optional */
|
2021-12-03 13:34:19 +00:00
|
|
|
{ "status.aheadBehind", "false" },
|
|
|
|
{ "commitGraph.generationVersion", "1" },
|
|
|
|
{ "core.autoCRLF", "false" },
|
|
|
|
{ "core.safeCRLF", "false" },
|
|
|
|
{ "fetch.showForcedUpdates", "false" },
|
|
|
|
{ NULL, NULL },
|
|
|
|
};
|
|
|
|
int i;
|
|
|
|
char *value;
|
|
|
|
|
|
|
|
for (i = 0; config[i].key; i++) {
|
2022-08-18 21:40:50 +00:00
|
|
|
if (set_scalar_config(config + i, reconfigure))
|
|
|
|
return error(_("could not configure %s=%s"),
|
|
|
|
config[i].key, config[i].value);
|
2021-12-03 13:34:19 +00:00
|
|
|
}
|
|
|
|
|
2022-08-18 21:40:51 +00:00
|
|
|
if (have_fsmonitor_support()) {
|
|
|
|
struct scalar_config fsmonitor = { "core.fsmonitor", "true" };
|
|
|
|
if (set_scalar_config(&fsmonitor, reconfigure))
|
|
|
|
return error(_("could not configure %s=%s"),
|
|
|
|
fsmonitor.key, fsmonitor.value);
|
2021-12-03 13:34:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The `log.excludeDecoration` setting is special because it allows
|
|
|
|
* for multiple values.
|
|
|
|
*/
|
|
|
|
if (git_config_get_string("log.excludeDecoration", &value)) {
|
|
|
|
trace2_data_string("scalar", the_repository,
|
|
|
|
"log.excludeDecoration", "created");
|
|
|
|
if (git_config_set_multivar_gently("log.excludeDecoration",
|
|
|
|
"refs/prefetch/*",
|
|
|
|
CONFIG_REGEX_NONE, 0))
|
|
|
|
return error(_("could not configure "
|
|
|
|
"log.excludeDecoration"));
|
|
|
|
} else {
|
|
|
|
trace2_data_string("scalar", the_repository,
|
|
|
|
"log.excludeDecoration", "exists");
|
|
|
|
free(value);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:20 +00:00
|
|
|
static int toggle_maintenance(int enable)
|
2021-12-03 13:34:19 +00:00
|
|
|
{
|
2021-12-03 13:34:20 +00:00
|
|
|
return run_git("maintenance", enable ? "start" : "unregister", NULL);
|
2021-12-03 13:34:19 +00:00
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:20 +00:00
|
|
|
static int add_or_remove_enlistment(int add)
|
2021-12-03 13:34:19 +00:00
|
|
|
{
|
|
|
|
int res;
|
|
|
|
|
|
|
|
if (!the_repository->worktree)
|
|
|
|
die(_("Scalar enlistments require a worktree"));
|
|
|
|
|
|
|
|
res = run_git("config", "--global", "--get", "--fixed-value",
|
|
|
|
"scalar.repo", the_repository->worktree, NULL);
|
|
|
|
|
|
|
|
/*
|
2021-12-03 13:34:20 +00:00
|
|
|
* If we want to add and the setting is already there, then do nothing.
|
|
|
|
* If we want to remove and the setting is not there, then do nothing.
|
2021-12-03 13:34:19 +00:00
|
|
|
*/
|
2021-12-03 13:34:20 +00:00
|
|
|
if ((add && !res) || (!add && res))
|
2021-12-03 13:34:19 +00:00
|
|
|
return 0;
|
|
|
|
|
2021-12-03 13:34:20 +00:00
|
|
|
return run_git("config", "--global", add ? "--add" : "--unset",
|
|
|
|
add ? "--no-fixed-value" : "--fixed-value",
|
2021-12-03 13:34:19 +00:00
|
|
|
"scalar.repo", the_repository->worktree, NULL);
|
|
|
|
}
|
|
|
|
|
2022-08-18 21:40:51 +00:00
|
|
|
static int start_fsmonitor_daemon(void)
|
|
|
|
{
|
|
|
|
assert(have_fsmonitor_support());
|
|
|
|
|
|
|
|
if (fsmonitor_ipc__get_state() != IPC_STATE__LISTENING)
|
|
|
|
return run_git("fsmonitor--daemon", "start", NULL);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-08-18 21:40:52 +00:00
|
|
|
static int stop_fsmonitor_daemon(void)
|
|
|
|
{
|
|
|
|
assert(have_fsmonitor_support());
|
|
|
|
|
|
|
|
if (fsmonitor_ipc__get_state() == IPC_STATE__LISTENING)
|
|
|
|
return run_git("fsmonitor--daemon", "stop", NULL);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:19 +00:00
|
|
|
static int register_dir(void)
|
|
|
|
{
|
2022-08-18 21:40:48 +00:00
|
|
|
if (add_or_remove_enlistment(1))
|
|
|
|
return error(_("could not add enlistment"));
|
2021-12-03 13:34:19 +00:00
|
|
|
|
2022-08-18 21:40:48 +00:00
|
|
|
if (set_recommended_config(0))
|
|
|
|
return error(_("could not set recommended config"));
|
2021-12-03 13:34:19 +00:00
|
|
|
|
2022-08-18 21:40:48 +00:00
|
|
|
if (toggle_maintenance(1))
|
|
|
|
return error(_("could not turn on maintenance"));
|
2021-12-03 13:34:20 +00:00
|
|
|
|
2022-08-18 21:40:51 +00:00
|
|
|
if (have_fsmonitor_support() && start_fsmonitor_daemon()) {
|
|
|
|
return error(_("could not start the FSMonitor daemon"));
|
|
|
|
}
|
|
|
|
|
2022-08-18 21:40:48 +00:00
|
|
|
return 0;
|
2021-12-03 13:34:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int unregister_dir(void)
|
|
|
|
{
|
|
|
|
int res = 0;
|
|
|
|
|
2022-08-18 21:40:47 +00:00
|
|
|
if (toggle_maintenance(0))
|
2022-08-18 21:40:48 +00:00
|
|
|
res = error(_("could not turn off maintenance"));
|
2021-12-03 13:34:20 +00:00
|
|
|
|
2022-08-18 21:40:47 +00:00
|
|
|
if (add_or_remove_enlistment(0))
|
2022-08-18 21:40:48 +00:00
|
|
|
res = error(_("could not remove enlistment"));
|
2021-12-03 13:34:19 +00:00
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:23 +00:00
|
|
|
/* printf-style interface, expects `<key>=<value>` argument */
|
|
|
|
static int set_config(const char *fmt, ...)
|
|
|
|
{
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
char *value;
|
|
|
|
int res;
|
|
|
|
va_list args;
|
|
|
|
|
|
|
|
va_start(args, fmt);
|
|
|
|
strbuf_vaddf(&buf, fmt, args);
|
|
|
|
va_end(args);
|
|
|
|
|
|
|
|
value = strchr(buf.buf, '=');
|
|
|
|
if (value)
|
|
|
|
*(value++) = '\0';
|
|
|
|
res = git_config_set_gently(buf.buf, value);
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *remote_default_branch(const char *url)
|
|
|
|
{
|
|
|
|
struct child_process cp = CHILD_PROCESS_INIT;
|
|
|
|
struct strbuf out = STRBUF_INIT;
|
|
|
|
|
|
|
|
cp.git_cmd = 1;
|
|
|
|
strvec_pushl(&cp.args, "ls-remote", "--symref", url, "HEAD", NULL);
|
|
|
|
if (!pipe_command(&cp, NULL, 0, &out, 0, NULL, 0)) {
|
|
|
|
const char *line = out.buf;
|
|
|
|
|
|
|
|
while (*line) {
|
|
|
|
const char *eol = strchrnul(line, '\n'), *p;
|
|
|
|
size_t len = eol - line;
|
|
|
|
char *branch;
|
|
|
|
|
|
|
|
if (!skip_prefix(line, "ref: ", &p) ||
|
|
|
|
!strip_suffix_mem(line, &len, "\tHEAD")) {
|
|
|
|
line = eol + (*eol == '\n');
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
eol = line + len;
|
|
|
|
if (skip_prefix(p, "refs/heads/", &p)) {
|
|
|
|
branch = xstrndup(p, eol - p);
|
|
|
|
strbuf_release(&out);
|
|
|
|
return branch;
|
|
|
|
}
|
|
|
|
|
|
|
|
error(_("remote HEAD is not a branch: '%.*s'"),
|
|
|
|
(int)(eol - p), p);
|
|
|
|
strbuf_release(&out);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
warning(_("failed to get default branch name from remote; "
|
|
|
|
"using local default"));
|
|
|
|
strbuf_reset(&out);
|
|
|
|
|
|
|
|
child_process_init(&cp);
|
|
|
|
cp.git_cmd = 1;
|
|
|
|
strvec_pushl(&cp.args, "symbolic-ref", "--short", "HEAD", NULL);
|
|
|
|
if (!pipe_command(&cp, NULL, 0, &out, 0, NULL, 0)) {
|
|
|
|
strbuf_trim(&out);
|
|
|
|
return strbuf_detach(&out, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_release(&out);
|
|
|
|
error(_("failed to get default branch name"));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:28 +00:00
|
|
|
static int delete_enlistment(struct strbuf *enlistment)
|
|
|
|
{
|
|
|
|
#ifdef WIN32
|
|
|
|
struct strbuf parent = STRBUF_INIT;
|
scalar: constrain enlistment search
Make the search for repository and enlistment root in
'setup_enlistment_directory()' more constrained to simplify behavior and
adhere to 'GIT_CEILING_DIRECTORIES'.
Previously, 'setup_enlistment_directory()' would check whether the provided
path (or current working directory) '<dir>' or its subdirectory '<dir>/src'
was a repository root. If not, the process would repeat on the parent of
'<dir>' until the repository was found or it reached the root of the
filesystem. This meant that a user could specify a path *anywhere* inside an
enlistment (including paths not in the repository contained within the
enlistment) and it would be found.
The downside to this process is that the search would not account for
'GIT_CEILING_DIRECTORIES', so the upward search could result in modifying
repository contents past 'GIT_CEILING_DIRECTORIES'. Similarly, operations
like 'scalar delete' could end up unintentionally deleting the parent of a
repo if its root was named 'src'.
To make this 'setup_enlistment_directory()' both adhere to
'GIT_CEILING_DIRECTORIES' and avoid unwanted deletions, the search for an
enlistment directory is simplified to:
- if '<dir>/src' is a repository root, '<dir>' is the enlistment root
- if '<dir>' is either the repository root or contained within a repository,
the repository root is the enlistment root
Now, only 'setup_git_directory()' (called by 'setup_enlistment_directory()')
searches upwards from the 'scalar' specified path, enforcing
'GIT_CEILING_DIRECTORIES' in the process. Additionally, 'scalar delete
<dir>/src' will not delete '<dir>' (if users would like to delete it, they
can still specify the enlistment root with 'scalar delete <dir>'). This is
true of any 'scalar' operation; users can invoke 'scalar' on the enlistment
root, but paths must otherwise be inside the repository to be valid.
To help clarify the updated behavior, new tests are added to
't9099-scalar.sh'.
Finally, this change leaves 'strbuf_parent_directory()' with only a single,
WIN32-specific caller in 'delete_enlistment()'. Rather than wrap
'strbuf_parent_directory()' in '#ifdef WIN32' to avoid the "unused function"
compiler error, move the contents of 'strbuf_parent_directory()' into
'delete_enlistment()' and remove the function.
Helped-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-18 21:40:46 +00:00
|
|
|
size_t offset;
|
|
|
|
char *path_sep;
|
2021-12-03 13:34:28 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
if (unregister_dir())
|
2022-08-18 21:40:49 +00:00
|
|
|
return error(_("failed to unregister repository"));
|
2021-12-03 13:34:28 +00:00
|
|
|
|
|
|
|
#ifdef WIN32
|
|
|
|
/*
|
|
|
|
* Change the current directory to one outside of the enlistment so
|
|
|
|
* that we may delete everything underneath it.
|
|
|
|
*/
|
scalar: constrain enlistment search
Make the search for repository and enlistment root in
'setup_enlistment_directory()' more constrained to simplify behavior and
adhere to 'GIT_CEILING_DIRECTORIES'.
Previously, 'setup_enlistment_directory()' would check whether the provided
path (or current working directory) '<dir>' or its subdirectory '<dir>/src'
was a repository root. If not, the process would repeat on the parent of
'<dir>' until the repository was found or it reached the root of the
filesystem. This meant that a user could specify a path *anywhere* inside an
enlistment (including paths not in the repository contained within the
enlistment) and it would be found.
The downside to this process is that the search would not account for
'GIT_CEILING_DIRECTORIES', so the upward search could result in modifying
repository contents past 'GIT_CEILING_DIRECTORIES'. Similarly, operations
like 'scalar delete' could end up unintentionally deleting the parent of a
repo if its root was named 'src'.
To make this 'setup_enlistment_directory()' both adhere to
'GIT_CEILING_DIRECTORIES' and avoid unwanted deletions, the search for an
enlistment directory is simplified to:
- if '<dir>/src' is a repository root, '<dir>' is the enlistment root
- if '<dir>' is either the repository root or contained within a repository,
the repository root is the enlistment root
Now, only 'setup_git_directory()' (called by 'setup_enlistment_directory()')
searches upwards from the 'scalar' specified path, enforcing
'GIT_CEILING_DIRECTORIES' in the process. Additionally, 'scalar delete
<dir>/src' will not delete '<dir>' (if users would like to delete it, they
can still specify the enlistment root with 'scalar delete <dir>'). This is
true of any 'scalar' operation; users can invoke 'scalar' on the enlistment
root, but paths must otherwise be inside the repository to be valid.
To help clarify the updated behavior, new tests are added to
't9099-scalar.sh'.
Finally, this change leaves 'strbuf_parent_directory()' with only a single,
WIN32-specific caller in 'delete_enlistment()'. Rather than wrap
'strbuf_parent_directory()' in '#ifdef WIN32' to avoid the "unused function"
compiler error, move the contents of 'strbuf_parent_directory()' into
'delete_enlistment()' and remove the function.
Helped-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-18 21:40:46 +00:00
|
|
|
offset = offset_1st_component(enlistment->buf);
|
|
|
|
path_sep = find_last_dir_sep(enlistment->buf + offset);
|
|
|
|
strbuf_add(&parent, enlistment->buf,
|
|
|
|
path_sep ? path_sep - enlistment->buf : offset);
|
2022-08-18 21:40:49 +00:00
|
|
|
if (chdir(parent.buf) < 0) {
|
|
|
|
int res = error_errno(_("could not switch to '%s'"), parent.buf);
|
|
|
|
strbuf_release(&parent);
|
|
|
|
return res;
|
|
|
|
}
|
2021-12-03 13:34:28 +00:00
|
|
|
strbuf_release(&parent);
|
|
|
|
#endif
|
|
|
|
|
2022-08-18 21:40:52 +00:00
|
|
|
if (have_fsmonitor_support() && stop_fsmonitor_daemon())
|
|
|
|
return error(_("failed to stop the FSMonitor daemon"));
|
|
|
|
|
2021-12-03 13:34:28 +00:00
|
|
|
if (remove_dir_recursively(enlistment, 0))
|
2022-08-18 21:40:49 +00:00
|
|
|
return error(_("failed to delete enlistment directory"));
|
2021-12-03 13:34:28 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:29 +00:00
|
|
|
/*
|
|
|
|
* Dummy implementation; Using `get_version_info()` would cause a link error
|
|
|
|
* without this.
|
|
|
|
*/
|
|
|
|
void load_builtin_commands(const char *prefix, struct cmdnames *cmds)
|
|
|
|
{
|
|
|
|
die("not implemented");
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:23 +00:00
|
|
|
static int cmd_clone(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
const char *branch = NULL;
|
2021-12-03 13:34:24 +00:00
|
|
|
int full_clone = 0, single_branch = 0;
|
2021-12-03 13:34:23 +00:00
|
|
|
struct option clone_options[] = {
|
|
|
|
OPT_STRING('b', "branch", &branch, N_("<branch>"),
|
|
|
|
N_("branch to checkout after clone")),
|
|
|
|
OPT_BOOL(0, "full-clone", &full_clone,
|
|
|
|
N_("when cloning, create full working directory")),
|
2021-12-03 13:34:24 +00:00
|
|
|
OPT_BOOL(0, "single-branch", &single_branch,
|
|
|
|
N_("only download metadata for the branch that will "
|
|
|
|
"be checked out")),
|
2021-12-03 13:34:23 +00:00
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
const char * const clone_usage[] = {
|
|
|
|
N_("scalar clone [<options>] [--] <repo> [<dir>]"),
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
const char *url;
|
|
|
|
char *enlistment = NULL, *dir = NULL;
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
int res;
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, NULL, clone_options, clone_usage, 0);
|
|
|
|
|
|
|
|
if (argc == 2) {
|
|
|
|
url = argv[0];
|
|
|
|
enlistment = xstrdup(argv[1]);
|
|
|
|
} else if (argc == 1) {
|
|
|
|
url = argv[0];
|
|
|
|
|
|
|
|
strbuf_addstr(&buf, url);
|
|
|
|
/* Strip trailing slashes, if any */
|
|
|
|
while (buf.len > 0 && is_dir_sep(buf.buf[buf.len - 1]))
|
|
|
|
strbuf_setlen(&buf, buf.len - 1);
|
|
|
|
/* Strip suffix `.git`, if any */
|
|
|
|
strbuf_strip_suffix(&buf, ".git");
|
|
|
|
|
|
|
|
enlistment = find_last_dir_sep(buf.buf);
|
|
|
|
if (!enlistment) {
|
|
|
|
die(_("cannot deduce worktree name from '%s'"), url);
|
|
|
|
}
|
|
|
|
enlistment = xstrdup(enlistment + 1);
|
|
|
|
} else {
|
|
|
|
usage_msg_opt(_("You must specify a repository to clone."),
|
|
|
|
clone_usage, clone_options);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (is_directory(enlistment))
|
|
|
|
die(_("directory '%s' exists already"), enlistment);
|
|
|
|
|
|
|
|
dir = xstrfmt("%s/src", enlistment);
|
|
|
|
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
if (branch)
|
|
|
|
strbuf_addf(&buf, "init.defaultBranch=%s", branch);
|
|
|
|
else {
|
|
|
|
char *b = repo_default_branch_name(the_repository, 1);
|
|
|
|
strbuf_addf(&buf, "init.defaultBranch=%s", b);
|
|
|
|
free(b);
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((res = run_git("-c", buf.buf, "init", "--", dir, NULL)))
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
if (chdir(dir) < 0) {
|
|
|
|
res = error_errno(_("could not switch to '%s'"), dir);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
setup_git_directory();
|
|
|
|
|
|
|
|
/* common-main already logs `argv` */
|
|
|
|
trace2_def_repo(the_repository);
|
|
|
|
|
|
|
|
if (!branch && !(branch = remote_default_branch(url))) {
|
|
|
|
res = error(_("failed to get default branch for '%s'"), url);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (set_config("remote.origin.url=%s", url) ||
|
|
|
|
set_config("remote.origin.fetch="
|
2021-12-03 13:34:24 +00:00
|
|
|
"+refs/heads/%s:refs/remotes/origin/%s",
|
|
|
|
single_branch ? branch : "*",
|
|
|
|
single_branch ? branch : "*") ||
|
2021-12-03 13:34:23 +00:00
|
|
|
set_config("remote.origin.promisor=true") ||
|
|
|
|
set_config("remote.origin.partialCloneFilter=blob:none")) {
|
|
|
|
res = error(_("could not configure remote in '%s'"), dir);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!full_clone &&
|
|
|
|
(res = run_git("sparse-checkout", "init", "--cone", NULL)))
|
|
|
|
goto cleanup;
|
|
|
|
|
2021-12-03 13:34:26 +00:00
|
|
|
if (set_recommended_config(0))
|
2021-12-03 13:34:23 +00:00
|
|
|
return error(_("could not configure '%s'"), dir);
|
|
|
|
|
|
|
|
if ((res = run_git("fetch", "--quiet", "origin", NULL))) {
|
|
|
|
warning(_("partial clone failed; attempting full clone"));
|
|
|
|
|
|
|
|
if (set_config("remote.origin.promisor") ||
|
|
|
|
set_config("remote.origin.partialCloneFilter")) {
|
|
|
|
res = error(_("could not configure for full clone"));
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((res = run_git("fetch", "--quiet", "origin", NULL)))
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((res = set_config("branch.%s.remote=origin", branch)))
|
|
|
|
goto cleanup;
|
|
|
|
if ((res = set_config("branch.%s.merge=refs/heads/%s",
|
|
|
|
branch, branch)))
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
strbuf_reset(&buf);
|
|
|
|
strbuf_addf(&buf, "origin/%s", branch);
|
|
|
|
res = run_git("checkout", "-f", "-t", buf.buf, NULL);
|
|
|
|
if (res)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
res = register_dir();
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
free(enlistment);
|
|
|
|
free(dir);
|
|
|
|
strbuf_release(&buf);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
scalar: implement `scalar diagnose`
Over the course of Scalar's development, it became obvious that there is
a need for a command that can gather all kinds of useful information
that can help identify the most typical problems with large
worktrees/repositories.
The `diagnose` command is the culmination of this hard-won knowledge: it
gathers the installed hooks, the config, a couple statistics describing
the data shape, among other pieces of information, and then wraps
everything up in a tidy, neat `.zip` archive.
Note: originally, Scalar was implemented in C# using the .NET API, where
we had the luxury of a comprehensive standard library that includes
basic functionality such as writing a `.zip` file. In the C version, we
lack such a commodity. Rather than introducing a dependency on, say,
libzip, we slightly abuse Git's `archive` machinery: we write out a
`.zip` of the empty try, augmented by a couple files that are added via
the `--add-file*` options. We are careful trying not to modify the
current repository in any way lest the very circumstances that required
`scalar diagnose` to be run are changed by the `diagnose` run itself.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-28 23:11:15 +00:00
|
|
|
static int cmd_diagnose(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
struct option options[] = {
|
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
const char * const usage[] = {
|
|
|
|
N_("scalar diagnose [<enlistment>]"),
|
|
|
|
NULL
|
|
|
|
};
|
2022-08-12 20:10:18 +00:00
|
|
|
struct strbuf diagnostics_root = STRBUF_INIT;
|
scalar: implement `scalar diagnose`
Over the course of Scalar's development, it became obvious that there is
a need for a command that can gather all kinds of useful information
that can help identify the most typical problems with large
worktrees/repositories.
The `diagnose` command is the culmination of this hard-won knowledge: it
gathers the installed hooks, the config, a couple statistics describing
the data shape, among other pieces of information, and then wraps
everything up in a tidy, neat `.zip` archive.
Note: originally, Scalar was implemented in C# using the .NET API, where
we had the luxury of a comprehensive standard library that includes
basic functionality such as writing a `.zip` file. In the C version, we
lack such a commodity. Rather than introducing a dependency on, say,
libzip, we slightly abuse Git's `archive` machinery: we write out a
`.zip` of the empty try, augmented by a couple files that are added via
the `--add-file*` options. We are careful trying not to modify the
current repository in any way lest the very circumstances that required
`scalar diagnose` to be run are changed by the `diagnose` run itself.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-28 23:11:15 +00:00
|
|
|
int res = 0;
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, NULL, options,
|
|
|
|
usage, 0);
|
|
|
|
|
2022-08-12 20:10:18 +00:00
|
|
|
setup_enlistment_directory(argc, argv, usage, options, &diagnostics_root);
|
|
|
|
strbuf_addstr(&diagnostics_root, "/.scalarDiagnostics");
|
scalar: implement `scalar diagnose`
Over the course of Scalar's development, it became obvious that there is
a need for a command that can gather all kinds of useful information
that can help identify the most typical problems with large
worktrees/repositories.
The `diagnose` command is the culmination of this hard-won knowledge: it
gathers the installed hooks, the config, a couple statistics describing
the data shape, among other pieces of information, and then wraps
everything up in a tidy, neat `.zip` archive.
Note: originally, Scalar was implemented in C# using the .NET API, where
we had the luxury of a comprehensive standard library that includes
basic functionality such as writing a `.zip` file. In the C version, we
lack such a commodity. Rather than introducing a dependency on, say,
libzip, we slightly abuse Git's `archive` machinery: we write out a
`.zip` of the empty try, augmented by a couple files that are added via
the `--add-file*` options. We are careful trying not to modify the
current repository in any way lest the very circumstances that required
`scalar diagnose` to be run are changed by the `diagnose` run itself.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-28 23:11:15 +00:00
|
|
|
|
2022-08-12 20:10:18 +00:00
|
|
|
res = run_git("diagnose", "--mode=all", "-s", "%Y%m%d_%H%M%S",
|
|
|
|
"-o", diagnostics_root.buf, NULL);
|
scalar: implement `scalar diagnose`
Over the course of Scalar's development, it became obvious that there is
a need for a command that can gather all kinds of useful information
that can help identify the most typical problems with large
worktrees/repositories.
The `diagnose` command is the culmination of this hard-won knowledge: it
gathers the installed hooks, the config, a couple statistics describing
the data shape, among other pieces of information, and then wraps
everything up in a tidy, neat `.zip` archive.
Note: originally, Scalar was implemented in C# using the .NET API, where
we had the luxury of a comprehensive standard library that includes
basic functionality such as writing a `.zip` file. In the C version, we
lack such a commodity. Rather than introducing a dependency on, say,
libzip, we slightly abuse Git's `archive` machinery: we write out a
`.zip` of the empty try, augmented by a couple files that are added via
the `--add-file*` options. We are careful trying not to modify the
current repository in any way lest the very circumstances that required
`scalar diagnose` to be run are changed by the `diagnose` run itself.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-28 23:11:15 +00:00
|
|
|
|
2022-08-12 20:10:18 +00:00
|
|
|
strbuf_release(&diagnostics_root);
|
scalar: implement `scalar diagnose`
Over the course of Scalar's development, it became obvious that there is
a need for a command that can gather all kinds of useful information
that can help identify the most typical problems with large
worktrees/repositories.
The `diagnose` command is the culmination of this hard-won knowledge: it
gathers the installed hooks, the config, a couple statistics describing
the data shape, among other pieces of information, and then wraps
everything up in a tidy, neat `.zip` archive.
Note: originally, Scalar was implemented in C# using the .NET API, where
we had the luxury of a comprehensive standard library that includes
basic functionality such as writing a `.zip` file. In the C version, we
lack such a commodity. Rather than introducing a dependency on, say,
libzip, we slightly abuse Git's `archive` machinery: we write out a
`.zip` of the empty try, augmented by a couple files that are added via
the `--add-file*` options. We are careful trying not to modify the
current repository in any way lest the very circumstances that required
`scalar diagnose` to be run are changed by the `diagnose` run itself.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-28 23:11:15 +00:00
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:22 +00:00
|
|
|
static int cmd_list(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
if (argc != 1)
|
|
|
|
die(_("`scalar list` does not take arguments"));
|
|
|
|
|
|
|
|
if (run_git("config", "--global", "--get-all", "scalar.repo", NULL) < 0)
|
|
|
|
return -1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:19 +00:00
|
|
|
static int cmd_register(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
struct option options[] = {
|
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
const char * const usage[] = {
|
|
|
|
N_("scalar register [<enlistment>]"),
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, NULL, options,
|
|
|
|
usage, 0);
|
|
|
|
|
|
|
|
setup_enlistment_directory(argc, argv, usage, options, NULL);
|
|
|
|
|
|
|
|
return register_dir();
|
|
|
|
}
|
scalar: create a rudimentary executable
The idea of Scalar (https://github.com/microsoft/scalar), and before
that, of VFS for Git, has always been to prove that Git _can_ scale, and
to upstream whatever strategies have been demonstrated to help.
With this patch, we start the journey from that C# project to move what
is left to Git's own `contrib/` directory, reimplementing it in pure C,
with the intention to facilitate integrating the functionality into core
Git all while maintaining backwards-compatibility for existing Scalar
users (which will be much easier when both live in the same worktree).
It has always been the plan to contribute all of the proven strategies
back to core Git.
For example, while the virtual filesystem provided by VFS for Git helped
the team developing the Windows operating system to move onto Git, while
trying to upstream it we realized that it cannot be done: getting the
virtual filesystem to work (which we only managed to implement fully on
Windows, but not on, say, macOS or Linux), and the required server-side
support for the GVFS protocol, made this not quite feasible.
The Scalar project learned from that and tackled the problem with
different tactics: instead of pretending to Git that the working
directory is fully populated, it _specifically_ teaches Git about
partial clone (which is based on VFS for Git's cache server), about
sparse checkout (which VFS for Git tried to do transparently, in the
file system layer), and regularly runs maintenance tasks to keep the
repository in a healthy state.
With partial clone, sparse checkout and `git maintenance` having been
upstreamed, there is little left that `scalar.exe` does which `git.exe`
cannot do. One such thing is that `scalar clone <url>` will
automatically set up a partial, sparse clone, and configure
known-helpful settings from the start.
So let's bring this convenience into Git's tree.
The idea here is that you can (optionally) build Scalar via
make -C contrib/scalar/
This will build the `scalar` executable and put it into the
contrib/scalar/ subdirectory.
The slightly awkward addition of the `contrib/scalar/*` bits to the
top-level `Makefile` are actually really required: we want to link to
`libgit.a`, which means that we will need to use the very same `CFLAGS`
and `LDFLAGS` as the rest of Git.
An early development version of this patch tried to replicate all the
conditional code in `contrib/scalar/Makefile` (e.g. `NO_POLL`) just like
`contrib/svn-fe/Makefile` used to do before it was retired. It turned
out to be quite the whack-a-mole game: the SHA-1-related flags, the
flags enabling/disabling `compat/poll/`, `compat/regex/`,
`compat/win32mmap.c` & friends depending on the current platform... To
put it mildly: it was a major mess.
Instead, this patch makes minimal changes to the top-level `Makefile` so
that the bits in `contrib/scalar/` can be compiled and linked, and
adds a `contrib/scalar/Makefile` that uses the top-level `Makefile` in a
most minimal way to do the actual compiling.
Note: With this commit, we only establish the infrastructure, no
Scalar functionality is implemented yet; We will do that incrementally
over the next few commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03 13:34:16 +00:00
|
|
|
|
2021-12-03 13:34:27 +00:00
|
|
|
static int get_scalar_repos(const char *key, const char *value, void *data)
|
|
|
|
{
|
|
|
|
struct string_list *list = data;
|
|
|
|
|
|
|
|
if (!strcmp(key, "scalar.repo"))
|
|
|
|
string_list_append(list, value);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:26 +00:00
|
|
|
static int cmd_reconfigure(int argc, const char **argv)
|
|
|
|
{
|
2021-12-03 13:34:27 +00:00
|
|
|
int all = 0;
|
2021-12-03 13:34:26 +00:00
|
|
|
struct option options[] = {
|
2021-12-03 13:34:27 +00:00
|
|
|
OPT_BOOL('a', "all", &all,
|
|
|
|
N_("reconfigure all registered enlistments")),
|
2021-12-03 13:34:26 +00:00
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
const char * const usage[] = {
|
2021-12-03 13:34:27 +00:00
|
|
|
N_("scalar reconfigure [--all | <enlistment>]"),
|
2021-12-03 13:34:26 +00:00
|
|
|
NULL
|
|
|
|
};
|
2021-12-03 13:34:27 +00:00
|
|
|
struct string_list scalar_repos = STRING_LIST_INIT_DUP;
|
|
|
|
int i, res = 0;
|
|
|
|
struct repository r = { NULL };
|
|
|
|
struct strbuf commondir = STRBUF_INIT, gitdir = STRBUF_INIT;
|
2021-12-03 13:34:26 +00:00
|
|
|
|
|
|
|
argc = parse_options(argc, argv, NULL, options,
|
|
|
|
usage, 0);
|
|
|
|
|
2021-12-03 13:34:27 +00:00
|
|
|
if (!all) {
|
|
|
|
setup_enlistment_directory(argc, argv, usage, options, NULL);
|
|
|
|
|
|
|
|
return set_recommended_config(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (argc > 0)
|
|
|
|
usage_msg_opt(_("--all or <enlistment>, but not both"),
|
|
|
|
usage, options);
|
|
|
|
|
|
|
|
git_config(get_scalar_repos, &scalar_repos);
|
2021-12-03 13:34:26 +00:00
|
|
|
|
2021-12-03 13:34:27 +00:00
|
|
|
for (i = 0; i < scalar_repos.nr; i++) {
|
|
|
|
const char *dir = scalar_repos.items[i].string;
|
|
|
|
|
|
|
|
strbuf_reset(&commondir);
|
|
|
|
strbuf_reset(&gitdir);
|
|
|
|
|
|
|
|
if (chdir(dir) < 0) {
|
|
|
|
warning_errno(_("could not switch to '%s'"), dir);
|
|
|
|
res = -1;
|
|
|
|
} else if (discover_git_directory(&commondir, &gitdir) < 0) {
|
|
|
|
warning_errno(_("git repository gone in '%s'"), dir);
|
|
|
|
res = -1;
|
|
|
|
} else {
|
|
|
|
git_config_clear();
|
|
|
|
|
|
|
|
the_repository = &r;
|
|
|
|
r.commondir = commondir.buf;
|
|
|
|
r.gitdir = gitdir.buf;
|
|
|
|
|
|
|
|
if (set_recommended_config(1) < 0)
|
|
|
|
res = -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
string_list_clear(&scalar_repos, 1);
|
|
|
|
strbuf_release(&commondir);
|
|
|
|
strbuf_release(&gitdir);
|
|
|
|
|
|
|
|
return res;
|
2021-12-03 13:34:26 +00:00
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:25 +00:00
|
|
|
static int cmd_run(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
struct option options[] = {
|
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
struct {
|
|
|
|
const char *arg, *task;
|
|
|
|
} tasks[] = {
|
|
|
|
{ "config", NULL },
|
|
|
|
{ "commit-graph", "commit-graph" },
|
|
|
|
{ "fetch", "prefetch" },
|
|
|
|
{ "loose-objects", "loose-objects" },
|
|
|
|
{ "pack-files", "incremental-repack" },
|
|
|
|
{ NULL, NULL }
|
|
|
|
};
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
const char *usagestr[] = { NULL, NULL };
|
|
|
|
int i;
|
|
|
|
|
|
|
|
strbuf_addstr(&buf, N_("scalar run <task> [<enlistment>]\nTasks:\n"));
|
|
|
|
for (i = 0; tasks[i].arg; i++)
|
|
|
|
strbuf_addf(&buf, "\t%s\n", tasks[i].arg);
|
|
|
|
usagestr[0] = buf.buf;
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, NULL, options,
|
|
|
|
usagestr, 0);
|
|
|
|
|
|
|
|
if (!argc)
|
|
|
|
usage_with_options(usagestr, options);
|
|
|
|
|
|
|
|
if (!strcmp("all", argv[0])) {
|
|
|
|
i = -1;
|
|
|
|
} else {
|
|
|
|
for (i = 0; tasks[i].arg && strcmp(tasks[i].arg, argv[0]); i++)
|
|
|
|
; /* keep looking for the task */
|
|
|
|
|
|
|
|
if (i > 0 && !tasks[i].arg) {
|
|
|
|
error(_("no such task: '%s'"), argv[0]);
|
|
|
|
usage_with_options(usagestr, options);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
argc--;
|
|
|
|
argv++;
|
|
|
|
setup_enlistment_directory(argc, argv, usagestr, options, NULL);
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
|
|
|
if (i == 0)
|
|
|
|
return register_dir();
|
|
|
|
|
|
|
|
if (i > 0)
|
|
|
|
return run_git("maintenance", "run",
|
|
|
|
"--task", tasks[i].task, NULL);
|
|
|
|
|
|
|
|
if (register_dir())
|
|
|
|
return -1;
|
|
|
|
for (i = 1; tasks[i].arg; i++)
|
|
|
|
if (run_git("maintenance", "run",
|
|
|
|
"--task", tasks[i].task, NULL))
|
|
|
|
return -1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:21 +00:00
|
|
|
static int remove_deleted_enlistment(struct strbuf *path)
|
|
|
|
{
|
|
|
|
int res = 0;
|
|
|
|
strbuf_realpath_forgiving(path, path->buf, 1);
|
|
|
|
|
|
|
|
if (run_git("config", "--global",
|
|
|
|
"--unset", "--fixed-value",
|
|
|
|
"scalar.repo", path->buf, NULL) < 0)
|
|
|
|
res = -1;
|
|
|
|
|
|
|
|
if (run_git("config", "--global",
|
|
|
|
"--unset", "--fixed-value",
|
|
|
|
"maintenance.repo", path->buf, NULL) < 0)
|
|
|
|
res = -1;
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:20 +00:00
|
|
|
static int cmd_unregister(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
struct option options[] = {
|
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
const char * const usage[] = {
|
|
|
|
N_("scalar unregister [<enlistment>]"),
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, NULL, options,
|
|
|
|
usage, 0);
|
|
|
|
|
2021-12-03 13:34:21 +00:00
|
|
|
/*
|
|
|
|
* Be forgiving when the enlistment or worktree does not even exist any
|
|
|
|
* longer; This can be the case if a user deleted the worktree by
|
|
|
|
* mistake and _still_ wants to unregister the thing.
|
|
|
|
*/
|
|
|
|
if (argc == 1) {
|
|
|
|
struct strbuf src_path = STRBUF_INIT, workdir_path = STRBUF_INIT;
|
|
|
|
|
|
|
|
strbuf_addf(&src_path, "%s/src/.git", argv[0]);
|
|
|
|
strbuf_addf(&workdir_path, "%s/.git", argv[0]);
|
|
|
|
if (!is_directory(src_path.buf) && !is_directory(workdir_path.buf)) {
|
|
|
|
/* remove possible matching registrations */
|
|
|
|
int res = -1;
|
|
|
|
|
|
|
|
strbuf_strip_suffix(&src_path, "/.git");
|
|
|
|
res = remove_deleted_enlistment(&src_path) && res;
|
|
|
|
|
|
|
|
strbuf_strip_suffix(&workdir_path, "/.git");
|
|
|
|
res = remove_deleted_enlistment(&workdir_path) && res;
|
|
|
|
|
|
|
|
strbuf_release(&src_path);
|
|
|
|
strbuf_release(&workdir_path);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
strbuf_release(&src_path);
|
|
|
|
strbuf_release(&workdir_path);
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:20 +00:00
|
|
|
setup_enlistment_directory(argc, argv, usage, options, NULL);
|
|
|
|
|
|
|
|
return unregister_dir();
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:28 +00:00
|
|
|
static int cmd_delete(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
char *cwd = xgetcwd();
|
|
|
|
struct option options[] = {
|
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
const char * const usage[] = {
|
|
|
|
N_("scalar delete <enlistment>"),
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
struct strbuf enlistment = STRBUF_INIT;
|
|
|
|
int res = 0;
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, NULL, options,
|
|
|
|
usage, 0);
|
|
|
|
|
|
|
|
if (argc != 1)
|
|
|
|
usage_with_options(usage, options);
|
|
|
|
|
|
|
|
setup_enlistment_directory(argc, argv, usage, options, &enlistment);
|
|
|
|
|
|
|
|
if (dir_inside_of(cwd, enlistment.buf) >= 0)
|
|
|
|
res = error(_("refusing to delete current working directory"));
|
|
|
|
else {
|
|
|
|
close_object_store(the_repository->objects);
|
|
|
|
res = delete_enlistment(&enlistment);
|
|
|
|
}
|
|
|
|
strbuf_release(&enlistment);
|
|
|
|
free(cwd);
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2022-09-02 15:56:45 +00:00
|
|
|
static int cmd_help(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
struct option options[] = {
|
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
const char * const usage[] = {
|
|
|
|
"scalar help",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, NULL, options,
|
|
|
|
usage, 0);
|
|
|
|
|
|
|
|
if (argc != 0)
|
|
|
|
usage_with_options(usage, options);
|
|
|
|
|
|
|
|
return run_git("help", "scalar", NULL);
|
|
|
|
}
|
|
|
|
|
2021-12-03 13:34:29 +00:00
|
|
|
static int cmd_version(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
int verbose = 0, build_options = 0;
|
|
|
|
struct option options[] = {
|
|
|
|
OPT__VERBOSE(&verbose, N_("include Git version")),
|
|
|
|
OPT_BOOL(0, "build-options", &build_options,
|
|
|
|
N_("include Git's build options")),
|
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
const char * const usage[] = {
|
|
|
|
N_("scalar verbose [-v | --verbose] [--build-options]"),
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, NULL, options,
|
|
|
|
usage, 0);
|
|
|
|
|
|
|
|
if (argc != 0)
|
|
|
|
usage_with_options(usage, options);
|
|
|
|
|
|
|
|
get_version_info(&buf, build_options);
|
|
|
|
fprintf(stderr, "%s\n", buf.buf);
|
|
|
|
strbuf_release(&buf);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
scalar: create a rudimentary executable
The idea of Scalar (https://github.com/microsoft/scalar), and before
that, of VFS for Git, has always been to prove that Git _can_ scale, and
to upstream whatever strategies have been demonstrated to help.
With this patch, we start the journey from that C# project to move what
is left to Git's own `contrib/` directory, reimplementing it in pure C,
with the intention to facilitate integrating the functionality into core
Git all while maintaining backwards-compatibility for existing Scalar
users (which will be much easier when both live in the same worktree).
It has always been the plan to contribute all of the proven strategies
back to core Git.
For example, while the virtual filesystem provided by VFS for Git helped
the team developing the Windows operating system to move onto Git, while
trying to upstream it we realized that it cannot be done: getting the
virtual filesystem to work (which we only managed to implement fully on
Windows, but not on, say, macOS or Linux), and the required server-side
support for the GVFS protocol, made this not quite feasible.
The Scalar project learned from that and tackled the problem with
different tactics: instead of pretending to Git that the working
directory is fully populated, it _specifically_ teaches Git about
partial clone (which is based on VFS for Git's cache server), about
sparse checkout (which VFS for Git tried to do transparently, in the
file system layer), and regularly runs maintenance tasks to keep the
repository in a healthy state.
With partial clone, sparse checkout and `git maintenance` having been
upstreamed, there is little left that `scalar.exe` does which `git.exe`
cannot do. One such thing is that `scalar clone <url>` will
automatically set up a partial, sparse clone, and configure
known-helpful settings from the start.
So let's bring this convenience into Git's tree.
The idea here is that you can (optionally) build Scalar via
make -C contrib/scalar/
This will build the `scalar` executable and put it into the
contrib/scalar/ subdirectory.
The slightly awkward addition of the `contrib/scalar/*` bits to the
top-level `Makefile` are actually really required: we want to link to
`libgit.a`, which means that we will need to use the very same `CFLAGS`
and `LDFLAGS` as the rest of Git.
An early development version of this patch tried to replicate all the
conditional code in `contrib/scalar/Makefile` (e.g. `NO_POLL`) just like
`contrib/svn-fe/Makefile` used to do before it was retired. It turned
out to be quite the whack-a-mole game: the SHA-1-related flags, the
flags enabling/disabling `compat/poll/`, `compat/regex/`,
`compat/win32mmap.c` & friends depending on the current platform... To
put it mildly: it was a major mess.
Instead, this patch makes minimal changes to the top-level `Makefile` so
that the bits in `contrib/scalar/` can be compiled and linked, and
adds a `contrib/scalar/Makefile` that uses the top-level `Makefile` in a
most minimal way to do the actual compiling.
Note: With this commit, we only establish the infrastructure, no
Scalar functionality is implemented yet; We will do that incrementally
over the next few commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03 13:34:16 +00:00
|
|
|
static struct {
|
|
|
|
const char *name;
|
|
|
|
int (*fn)(int, const char **);
|
|
|
|
} builtins[] = {
|
2021-12-03 13:34:23 +00:00
|
|
|
{ "clone", cmd_clone },
|
2021-12-03 13:34:22 +00:00
|
|
|
{ "list", cmd_list },
|
2021-12-03 13:34:19 +00:00
|
|
|
{ "register", cmd_register },
|
2021-12-03 13:34:20 +00:00
|
|
|
{ "unregister", cmd_unregister },
|
2021-12-03 13:34:25 +00:00
|
|
|
{ "run", cmd_run },
|
2021-12-03 13:34:26 +00:00
|
|
|
{ "reconfigure", cmd_reconfigure },
|
2021-12-03 13:34:28 +00:00
|
|
|
{ "delete", cmd_delete },
|
2022-09-02 15:56:45 +00:00
|
|
|
{ "help", cmd_help },
|
2021-12-03 13:34:29 +00:00
|
|
|
{ "version", cmd_version },
|
scalar: implement `scalar diagnose`
Over the course of Scalar's development, it became obvious that there is
a need for a command that can gather all kinds of useful information
that can help identify the most typical problems with large
worktrees/repositories.
The `diagnose` command is the culmination of this hard-won knowledge: it
gathers the installed hooks, the config, a couple statistics describing
the data shape, among other pieces of information, and then wraps
everything up in a tidy, neat `.zip` archive.
Note: originally, Scalar was implemented in C# using the .NET API, where
we had the luxury of a comprehensive standard library that includes
basic functionality such as writing a `.zip` file. In the C version, we
lack such a commodity. Rather than introducing a dependency on, say,
libzip, we slightly abuse Git's `archive` machinery: we write out a
`.zip` of the empty try, augmented by a couple files that are added via
the `--add-file*` options. We are careful trying not to modify the
current repository in any way lest the very circumstances that required
`scalar diagnose` to be run are changed by the `diagnose` run itself.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-28 23:11:15 +00:00
|
|
|
{ "diagnose", cmd_diagnose },
|
scalar: create a rudimentary executable
The idea of Scalar (https://github.com/microsoft/scalar), and before
that, of VFS for Git, has always been to prove that Git _can_ scale, and
to upstream whatever strategies have been demonstrated to help.
With this patch, we start the journey from that C# project to move what
is left to Git's own `contrib/` directory, reimplementing it in pure C,
with the intention to facilitate integrating the functionality into core
Git all while maintaining backwards-compatibility for existing Scalar
users (which will be much easier when both live in the same worktree).
It has always been the plan to contribute all of the proven strategies
back to core Git.
For example, while the virtual filesystem provided by VFS for Git helped
the team developing the Windows operating system to move onto Git, while
trying to upstream it we realized that it cannot be done: getting the
virtual filesystem to work (which we only managed to implement fully on
Windows, but not on, say, macOS or Linux), and the required server-side
support for the GVFS protocol, made this not quite feasible.
The Scalar project learned from that and tackled the problem with
different tactics: instead of pretending to Git that the working
directory is fully populated, it _specifically_ teaches Git about
partial clone (which is based on VFS for Git's cache server), about
sparse checkout (which VFS for Git tried to do transparently, in the
file system layer), and regularly runs maintenance tasks to keep the
repository in a healthy state.
With partial clone, sparse checkout and `git maintenance` having been
upstreamed, there is little left that `scalar.exe` does which `git.exe`
cannot do. One such thing is that `scalar clone <url>` will
automatically set up a partial, sparse clone, and configure
known-helpful settings from the start.
So let's bring this convenience into Git's tree.
The idea here is that you can (optionally) build Scalar via
make -C contrib/scalar/
This will build the `scalar` executable and put it into the
contrib/scalar/ subdirectory.
The slightly awkward addition of the `contrib/scalar/*` bits to the
top-level `Makefile` are actually really required: we want to link to
`libgit.a`, which means that we will need to use the very same `CFLAGS`
and `LDFLAGS` as the rest of Git.
An early development version of this patch tried to replicate all the
conditional code in `contrib/scalar/Makefile` (e.g. `NO_POLL`) just like
`contrib/svn-fe/Makefile` used to do before it was retired. It turned
out to be quite the whack-a-mole game: the SHA-1-related flags, the
flags enabling/disabling `compat/poll/`, `compat/regex/`,
`compat/win32mmap.c` & friends depending on the current platform... To
put it mildly: it was a major mess.
Instead, this patch makes minimal changes to the top-level `Makefile` so
that the bits in `contrib/scalar/` can be compiled and linked, and
adds a `contrib/scalar/Makefile` that uses the top-level `Makefile` in a
most minimal way to do the actual compiling.
Note: With this commit, we only establish the infrastructure, no
Scalar functionality is implemented yet; We will do that incrementally
over the next few commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03 13:34:16 +00:00
|
|
|
{ NULL, NULL},
|
|
|
|
};
|
|
|
|
|
|
|
|
int cmd_main(int argc, const char **argv)
|
|
|
|
{
|
|
|
|
struct strbuf scalar_usage = STRBUF_INIT;
|
|
|
|
int i;
|
|
|
|
|
2022-01-28 14:31:57 +00:00
|
|
|
while (argc > 1 && *argv[1] == '-') {
|
|
|
|
if (!strcmp(argv[1], "-C")) {
|
|
|
|
if (argc < 3)
|
|
|
|
die(_("-C requires a <directory>"));
|
|
|
|
if (chdir(argv[2]) < 0)
|
|
|
|
die_errno(_("could not change to '%s'"),
|
|
|
|
argv[2]);
|
|
|
|
argc -= 2;
|
|
|
|
argv += 2;
|
|
|
|
} else if (!strcmp(argv[1], "-c")) {
|
|
|
|
if (argc < 3)
|
|
|
|
die(_("-c requires a <key>=<value> argument"));
|
|
|
|
git_config_push_parameter(argv[2]);
|
|
|
|
argc -= 2;
|
|
|
|
argv += 2;
|
|
|
|
} else
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
scalar: create a rudimentary executable
The idea of Scalar (https://github.com/microsoft/scalar), and before
that, of VFS for Git, has always been to prove that Git _can_ scale, and
to upstream whatever strategies have been demonstrated to help.
With this patch, we start the journey from that C# project to move what
is left to Git's own `contrib/` directory, reimplementing it in pure C,
with the intention to facilitate integrating the functionality into core
Git all while maintaining backwards-compatibility for existing Scalar
users (which will be much easier when both live in the same worktree).
It has always been the plan to contribute all of the proven strategies
back to core Git.
For example, while the virtual filesystem provided by VFS for Git helped
the team developing the Windows operating system to move onto Git, while
trying to upstream it we realized that it cannot be done: getting the
virtual filesystem to work (which we only managed to implement fully on
Windows, but not on, say, macOS or Linux), and the required server-side
support for the GVFS protocol, made this not quite feasible.
The Scalar project learned from that and tackled the problem with
different tactics: instead of pretending to Git that the working
directory is fully populated, it _specifically_ teaches Git about
partial clone (which is based on VFS for Git's cache server), about
sparse checkout (which VFS for Git tried to do transparently, in the
file system layer), and regularly runs maintenance tasks to keep the
repository in a healthy state.
With partial clone, sparse checkout and `git maintenance` having been
upstreamed, there is little left that `scalar.exe` does which `git.exe`
cannot do. One such thing is that `scalar clone <url>` will
automatically set up a partial, sparse clone, and configure
known-helpful settings from the start.
So let's bring this convenience into Git's tree.
The idea here is that you can (optionally) build Scalar via
make -C contrib/scalar/
This will build the `scalar` executable and put it into the
contrib/scalar/ subdirectory.
The slightly awkward addition of the `contrib/scalar/*` bits to the
top-level `Makefile` are actually really required: we want to link to
`libgit.a`, which means that we will need to use the very same `CFLAGS`
and `LDFLAGS` as the rest of Git.
An early development version of this patch tried to replicate all the
conditional code in `contrib/scalar/Makefile` (e.g. `NO_POLL`) just like
`contrib/svn-fe/Makefile` used to do before it was retired. It turned
out to be quite the whack-a-mole game: the SHA-1-related flags, the
flags enabling/disabling `compat/poll/`, `compat/regex/`,
`compat/win32mmap.c` & friends depending on the current platform... To
put it mildly: it was a major mess.
Instead, this patch makes minimal changes to the top-level `Makefile` so
that the bits in `contrib/scalar/` can be compiled and linked, and
adds a `contrib/scalar/Makefile` that uses the top-level `Makefile` in a
most minimal way to do the actual compiling.
Note: With this commit, we only establish the infrastructure, no
Scalar functionality is implemented yet; We will do that incrementally
over the next few commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03 13:34:16 +00:00
|
|
|
if (argc > 1) {
|
|
|
|
argv++;
|
|
|
|
argc--;
|
|
|
|
|
|
|
|
for (i = 0; builtins[i].name; i++)
|
|
|
|
if (!strcmp(builtins[i].name, argv[0]))
|
|
|
|
return !!builtins[i].fn(argc, argv);
|
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_addstr(&scalar_usage,
|
2022-01-28 14:31:57 +00:00
|
|
|
N_("scalar [-C <directory>] [-c <key>=<value>] "
|
|
|
|
"<command> [<options>]\n\nCommands:\n"));
|
scalar: create a rudimentary executable
The idea of Scalar (https://github.com/microsoft/scalar), and before
that, of VFS for Git, has always been to prove that Git _can_ scale, and
to upstream whatever strategies have been demonstrated to help.
With this patch, we start the journey from that C# project to move what
is left to Git's own `contrib/` directory, reimplementing it in pure C,
with the intention to facilitate integrating the functionality into core
Git all while maintaining backwards-compatibility for existing Scalar
users (which will be much easier when both live in the same worktree).
It has always been the plan to contribute all of the proven strategies
back to core Git.
For example, while the virtual filesystem provided by VFS for Git helped
the team developing the Windows operating system to move onto Git, while
trying to upstream it we realized that it cannot be done: getting the
virtual filesystem to work (which we only managed to implement fully on
Windows, but not on, say, macOS or Linux), and the required server-side
support for the GVFS protocol, made this not quite feasible.
The Scalar project learned from that and tackled the problem with
different tactics: instead of pretending to Git that the working
directory is fully populated, it _specifically_ teaches Git about
partial clone (which is based on VFS for Git's cache server), about
sparse checkout (which VFS for Git tried to do transparently, in the
file system layer), and regularly runs maintenance tasks to keep the
repository in a healthy state.
With partial clone, sparse checkout and `git maintenance` having been
upstreamed, there is little left that `scalar.exe` does which `git.exe`
cannot do. One such thing is that `scalar clone <url>` will
automatically set up a partial, sparse clone, and configure
known-helpful settings from the start.
So let's bring this convenience into Git's tree.
The idea here is that you can (optionally) build Scalar via
make -C contrib/scalar/
This will build the `scalar` executable and put it into the
contrib/scalar/ subdirectory.
The slightly awkward addition of the `contrib/scalar/*` bits to the
top-level `Makefile` are actually really required: we want to link to
`libgit.a`, which means that we will need to use the very same `CFLAGS`
and `LDFLAGS` as the rest of Git.
An early development version of this patch tried to replicate all the
conditional code in `contrib/scalar/Makefile` (e.g. `NO_POLL`) just like
`contrib/svn-fe/Makefile` used to do before it was retired. It turned
out to be quite the whack-a-mole game: the SHA-1-related flags, the
flags enabling/disabling `compat/poll/`, `compat/regex/`,
`compat/win32mmap.c` & friends depending on the current platform... To
put it mildly: it was a major mess.
Instead, this patch makes minimal changes to the top-level `Makefile` so
that the bits in `contrib/scalar/` can be compiled and linked, and
adds a `contrib/scalar/Makefile` that uses the top-level `Makefile` in a
most minimal way to do the actual compiling.
Note: With this commit, we only establish the infrastructure, no
Scalar functionality is implemented yet; We will do that incrementally
over the next few commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03 13:34:16 +00:00
|
|
|
for (i = 0; builtins[i].name; i++)
|
|
|
|
strbuf_addf(&scalar_usage, "\t%s\n", builtins[i].name);
|
|
|
|
|
|
|
|
usage(scalar_usage.buf);
|
|
|
|
}
|