mirror of https://github.com/git/git synced 2024-08-27 03:29:21 +00:00

History

Ævar Arnfjörð Bjarmason 8df786d298 Makefiles: add "shared.mak", move ".DELETE_ON_ERROR" to it We have various behavior that's shared across our Makefiles, or that really should be (e.g. via defined templates). Let's create a top-level "shared.mak" to house those sorts of things, and start by adding the ".DELETE_ON_ERROR" flag to it. See my own `7b76d6bf22` (Makefile: add and use the ".DELETE_ON_ERROR" flag, 2021-06-29) and `db10fc6c09` (doc: simplify Makefile using .DELETE_ON_ERROR, 2021-05-21) for the addition and use of the ".DELETE_ON_ERROR" flag. I.e. this changes the behavior of existing rules in the altered Makefiles (except "Makefile" & "Documentation/Makefile"). I'm confident that this is safe having read the relevant rules in those Makfiles, and as the GNU make manual notes that it isn't the default behavior is out of an abundance of backwards compatibility caution. From edition 0.75 of its manual, covering GNU make 4.3: [Enabling '.DELETE_ON_ERROR' is] almost always what you want 'make' to do, but it is not historical practice; so for compatibility, you must explicitly request it. This doesn't introduce a bug by e.g. having this ".DELETE_ON_ERROR" flag only apply to this new shared.mak, Makefiles have no such scoping semantics. It does increase the danger that any Makefile without an explicit "The default target of this Makefile is..." snippet to define the default target as "all" could have its default rule changed if our new shared.mak ever defines a "real" rule. In subsequent commits we'll be careful not to do that, and such breakage would be obvious e.g. in the case of "make -C t". We might want to make that less fragile still (e.g. by using ".DEFAULT_GOAL" as noted in the preceding commit), but for now let's simply include "shared.mak" without adding that boilerplate to all the Makefiles that don't have it already. Most of those are already exposed to that potential caveat e.g. due to including "config.mak*". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>		2022-03-03 14:14:55 -08:00
..
t	Makefiles: add "shared.mak", move ".DELETE_ON_ERROR" to it	2022-03-03 14:14:55 -08:00
.gitignore	scalar: create a rudimentary executable	2021-12-04 21:52:23 -08:00
Makefile	Makefiles: add "shared.mak", move ".DELETE_ON_ERROR" to it	2022-03-03 14:14:55 -08:00
README.md
scalar.c	scalar: accept -C and -c options before the subcommand	2022-01-28 15:14:38 -08:00
scalar.txt	scalar: accept -C and -c options before the subcommand	2022-01-28 15:14:38 -08:00

README.md

Scalar - an opinionated repository management tool

Scalar is an add-on to Git that helps users take advantage of advanced performance features in Git. Originally implemented in C# using .NET Core, based on the learnings from the VFS for Git project, most of the techniques developed by the Scalar project have been integrated into core Git already:

partial clone,
commit graphs,
multi-pack index,
sparse checkout (cone mode),
scheduled background maintenance,
etc

This directory contains the remaining parts of Scalar that are not (yet) in core Git.

Roadmap

The idea is to populate this directory via incremental patch series and eventually move to a top-level directory next to gitk-git/ and to git-gui/. The current plan involves the following patch series:

scalar-the-beginning: The initial patch series which sets up contrib/scalar/ and populates it with a minimal scalar command that demonstrates the fundamental ideas.
scalar-c-and-C: The scalar command learns about two options that can be specified before the command, -c <key>=<value> and -C <directory>.
scalar-diagnose: The scalar command is taught the diagnose subcommand.
scalar-and-builtin-fsmonitor: The built-in FSMonitor is enabled in scalar register and in scalar clone, for an enormous performance boost when working in large worktrees. This patch series necessarily depends on Jeff Hostetler's FSMonitor patch series to be integrated into Git.
scalar-gentler-config-locking: Scalar enlistments are registered in the user's Git config. This usually does not represent any problem because it is rare for a user to register an enlistment. However, in Scalar's functional tests, Scalar enlistments are created galore, and in parallel, which can lead to lock contention. This patch series works around that problem by re-trying to lock the config file in a gentle fashion.
scalar-extra-docs: Add some extensive documentation that has been written in the original Scalar project (all subject to discussion, of course).
optionally-install-scalar: Now that Scalar is feature (and documentation) complete and is verified in CI builds, let's offer to install it.
move-scalar-to-toplevel: Now that Scalar is complete, let's move it next to gitk-git/ and to git-gui/, making it a top-level command.

The following two patch series exist in Microsoft's fork of Git and are publicly available. There is no current plan to upstream them, not because I want to withhold these patches, but because I don't think the Git community is interested in these patches.

There are some interesting ideas there, but the implementation is too specific to Azure Repos and/or VFS for Git to be of much help in general (and also: my colleagues tried to upstream some patches already and the enthusiasm for integrating things related to Azure Repos and VFS for Git can be summarized in very, very few words).

These still exist mainly because the GVFS protocol is what Azure Repos has instead of partial clone, while Git is focused on improving partial clone:

scalar-with-gvfs: The primary purpose of this patch series is to support existing Scalar users whose repositories are hosted in Azure Repos (which does not support Git's partial clones, but supports its predecessor, the GVFS protocol, which is used by Scalar to emulate the partial clone).

Since the GVFS protocol will never be supported by core Git, this patch series will remain in Microsoft's fork of Git.
run-scalar-functional-tests: The Scalar project developed a quite comprehensive set of integration tests (or, "Functional Tests"). They are the sole remaining part of the original C#-based Scalar project, and this patch adds a GitHub workflow that runs them all.

Since the tests partially depend on features that are only provided in the scalar-with-gvfs patch series, this patch cannot be upstreamed.