mirror of
https://github.com/git-for-windows/git.git
synced 2026-06-28 06:35:27 -05:00
9759608622
The Git project is not exactly the easiest project to get started in: it's written in C and POSIX shell, with bits of Perl, Rust and other languages sprinkled into it. On top of that, the project has grown somewhat organically over time, making the codebase hard to navigate. These are problems that we're aware of, and there have been and still are efforts to clean up some of the technical debt that is natural to exist an a project that is more than 20 years old. Furthermore, we provide resources to newcomers that help them out like our coding guidelines, code of conduct or "MyFirstContribution.adoc". But there is a rather practical problem: finding your way around in our project's tree is not easy. Doing a directory listing in the top-level directory will present you with more than 550 files, which makes it extremely hard for a newcomer to figure out what files they are even supposed to look at. This makes the onboarding experience somewhat harder than it really needs to be. This isn't only a problem for newcomers though, as I myself struggle to find the files I am looking for because of the sheer number of files. Besides the problem of discoverability it also creates a problem of structure. It is not obvious at all which files are part of "libgit.a" and which files are only linked into our final executables. So while we have this split in our build systems, that split is not evident at all in our tree. Introduce a new "lib/" directory and move all of our sources for "libgit.a" into it to fix these issues. It makes the split we have evident and reduces the number of files in our top-level tree from 550 files to ~80 files. This is still a lot of files, but it's significantly easier to navigate already. Furthermore, we can further iterate after this step and think about introducing a better structure for remaining files, as well. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
50 lines
1.8 KiB
C
50 lines
1.8 KiB
C
#ifndef SPARSE_INDEX_H__
|
|
#define SPARSE_INDEX_H__
|
|
|
|
/*
|
|
* If performing an operation where the index is supposed to expand to a
|
|
* full index, then disable the advice message by setting this global to
|
|
* zero.
|
|
*/
|
|
extern int give_advice_on_expansion;
|
|
|
|
struct index_state;
|
|
#define SPARSE_INDEX_MEMORY_ONLY (1 << 0)
|
|
int is_sparse_index_allowed(struct index_state *istate, int flags);
|
|
int convert_to_sparse(struct index_state *istate, int flags);
|
|
void ensure_correct_sparsity(struct index_state *istate);
|
|
void clear_skip_worktree_from_present_files(struct index_state *istate);
|
|
|
|
/*
|
|
* Some places in the codebase expect to search for a specific path.
|
|
* This path might be outside of the sparse-checkout definition, in
|
|
* which case a sparse-index may not contain a path for that index.
|
|
*
|
|
* Given an index and a path, check to see if a leading directory for
|
|
* 'path' exists in the index as a sparse directory. In that case,
|
|
* expand that sparse directory to a full range of cache entries and
|
|
* populate the index accordingly.
|
|
*/
|
|
void expand_to_path(struct index_state *istate,
|
|
const char *path, size_t pathlen, int icase);
|
|
|
|
struct repository;
|
|
int set_sparse_index_config(struct repository *repo, int enable);
|
|
|
|
struct pattern_list;
|
|
|
|
/**
|
|
* Scan the given index and compare its entries to the given pattern list.
|
|
* If the index is sparse and the pattern list uses cone mode patterns,
|
|
* then modify the index to contain the all of the file entries within that
|
|
* new pattern list. This expands sparse directories only as far as needed.
|
|
*
|
|
* If the pattern list is NULL or does not use cone mode patterns, then the
|
|
* index is expanded to a full index.
|
|
*/
|
|
void expand_index(struct index_state *istate, struct pattern_list *pl);
|
|
|
|
void ensure_full_index(struct index_state *istate);
|
|
|
|
#endif
|