|
|
|
|
/fuzz-commit-graph
|
|
|
|
|
/fuzz_corpora
|
|
|
|
|
/fuzz-pack-headers
|
|
|
|
|
/fuzz-pack-idx
|
|
|
|
|
/GIT-BUILD-OPTIONS
|
|
|
|
|
/GIT-CFLAGS
|
|
|
|
|
/GIT-LDFLAGS
|
|
|
|
|
/GIT-PREFIX
|
|
|
|
|
/GIT-PERL-DEFINES
|
|
|
|
|
/GIT-PERL-HEADER
|
|
|
|
|
/GIT-PYTHON-VARS
|
|
|
|
|
/GIT-SCRIPT-DEFINES
|
|
|
|
|
/GIT-USER-AGENT
|
|
|
|
|
/GIT-VERSION-FILE
|
|
|
|
|
/bin-wrappers/
|
|
|
|
|
/git
|
|
|
|
|
/git-add
|
|
|
|
|
/git-add--interactive
|
|
|
|
|
/git-am
|
|
|
|
|
/git-annotate
|
|
|
|
|
/git-apply
|
|
|
|
|
/git-archimport
|
|
|
|
|
/git-archive
|
|
|
|
|
/git-bisect
|
|
|
|
|
/git-bisect--helper
|
|
|
|
|
/git-blame
|
|
|
|
|
/git-branch
|
|
|
|
|
/git-bugreport
|
|
|
|
|
/git-bundle
|
|
|
|
|
/git-cat-file
|
|
|
|
|
/git-check-attr
|
|
|
|
|
/git-check-ignore
|
|
|
|
|
/git-check-mailmap
|
|
|
|
|
/git-check-ref-format
|
|
|
|
|
/git-checkout
|
parallel-checkout: make it truly parallel
Use multiple worker processes to distribute the queued entries and call
write_pc_item() in parallel for them. The items are distributed
uniformly in contiguous chunks. This minimizes the chances of two
workers writing to the same directory simultaneously, which could affect
performance due to lock contention in the kernel. Work stealing (or any
other format of re-distribution) is not implemented yet.
The protocol between the main process and the workers is quite simple.
They exchange binary messages packed in pkt-line format, and use
PKT-FLUSH to mark the end of input (from both sides). The main process
starts the communication by sending N pkt-lines, each corresponding to
an item that needs to be written. These packets contain all the
necessary information to load, smudge, and write the blob associated
with each item. Then it waits for the worker to send back N pkt-lines
containing the results for each item. The resulting packet must contain:
the identification number of the item that it refers to, the status of
the operation, and the lstat() data gathered after writing the file (iff
the operation was successful).
For now, checkout always uses a hardcoded value of 2 workers, only to
demonstrate that the parallel checkout framework correctly divides and
writes the queued entries. The next patch will add user configurations
and define a more reasonable default, based on tests with the said
settings.
Co-authored-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Co-authored-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
4 years ago
|
|
|
/git-checkout--worker
|
|
|
|
|
/git-checkout-index
|
|
|
|
|
/git-cherry
|
|
|
|
|
/git-cherry-pick
|
|
|
|
|
/git-clean
|
|
|
|
|
/git-clone
|
|
|
|
|
/git-column
|
|
|
|
|
/git-commit
|
|
|
|
|
/git-commit-graph
|
|
|
|
|
/git-commit-tree
|
|
|
|
|
/git-config
|
|
|
|
|
/git-count-objects
|
|
|
|
|
/git-credential
|
|
|
|
|
/git-credential-cache
|
|
|
|
|
/git-credential-cache--daemon
|
|
|
|
|
/git-credential-store
|
|
|
|
|
/git-cvsexportcommit
|
|
|
|
|
/git-cvsimport
|
|
|
|
|
/git-cvsserver
|
|
|
|
|
/git-daemon
|
|
|
|
|
/git-diff
|
|
|
|
|
/git-diff-files
|
|
|
|
|
/git-diff-index
|
|
|
|
|
/git-diff-tree
|
|
|
|
|
/git-difftool
|
|
|
|
|
/git-difftool--helper
|
|
|
|
|
/git-describe
|
|
|
|
|
/git-env--helper
|
|
|
|
|
/git-fast-export
|
|
|
|
|
/git-fast-import
|
|
|
|
|
/git-fetch
|
|
|
|
|
/git-fetch-pack
|
|
|
|
|
/git-filter-branch
|
|
|
|
|
/git-fmt-merge-msg
|
|
|
|
|
/git-for-each-ref
|
|
|
|
|
/git-for-each-repo
|
|
|
|
|
/git-format-patch
|
|
|
|
|
/git-fsck
|
|
|
|
|
/git-fsck-objects
|
|
|
|
|
/git-fsmonitor--daemon
|
|
|
|
|
/git-gc
|
|
|
|
|
/git-get-tar-commit-id
|
|
|
|
|
/git-grep
|
|
|
|
|
/git-hash-object
|
|
|
|
|
/git-help
|
|
|
|
|
/git-hook
|
|
|
|
|
/git-http-backend
|
|
|
|
|
/git-http-fetch
|
|
|
|
|
/git-http-push
|
|
|
|
|
/git-imap-send
|
|
|
|
|
/git-index-pack
|
|
|
|
|
/git-init
|
|
|
|
|
/git-init-db
|
|
|
|
|
/git-interpret-trailers
|
|
|
|
|
/git-instaweb
|
|
|
|
|
/git-log
|
|
|
|
|
/git-ls-files
|
|
|
|
|
/git-ls-remote
|
|
|
|
|
/git-ls-tree
|
|
|
|
|
/git-mailinfo
|
|
|
|
|
/git-mailsplit
|
maintenance: create basic maintenance runner
The 'gc' builtin is our current entrypoint for automatically maintaining
a repository. This one tool does many operations, such as repacking the
repository, packing refs, and rewriting the commit-graph file. The name
implies it performs "garbage collection" which means several different
things, and some users may not want to use this operation that rewrites
the entire object database.
Create a new 'maintenance' builtin that will become a more general-
purpose command. To start, it will only support the 'run' subcommand,
but will later expand to add subcommands for scheduling maintenance in
the background.
For now, the 'maintenance' builtin is a thin shim over the 'gc' builtin.
In fact, the only option is the '--auto' toggle, which is handed
directly to the 'gc' builtin. The current change is isolated to this
simple operation to prevent more interesting logic from being lost in
all of the boilerplate of adding a new builtin.
Use existing builtin/gc.c file because we want to share code between the
two builtins. It is possible that we will have 'maintenance' replace the
'gc' builtin entirely at some point, leaving 'git gc' as an alias for
some specific arguments to 'git maintenance run'.
Create a new test_subcommand helper that allows us to test if a certain
subcommand was run. It requires storing the GIT_TRACE2_EVENT logs in a
file. A negation mode is available that will be used in later tests.
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
4 years ago
|
|
|
/git-maintenance
|
|
|
|
|
/git-merge
|
|
|
|
|
/git-merge-base
|
|
|
|
|
/git-merge-index
|
|
|
|
|
/git-merge-file
|
|
|
|
|
/git-merge-tree
|
|
|
|
|
/git-merge-octopus
|
|
|
|
|
/git-merge-one-file
|
|
|
|
|
/git-merge-ours
|
|
|
|
|
/git-merge-recursive
|
|
|
|
|
/git-merge-resolve
|
|
|
|
|
/git-merge-subtree
|
|
|
|
|
/git-mergetool
|
|
|
|
|
/git-mergetool--lib
|
|
|
|
|
/git-mktag
|
|
|
|
|
/git-mktree
|
|
|
|
|
/git-multi-pack-index
|
|
|
|
|
/git-mv
|
|
|
|
|
/git-name-rev
|
|
|
|
|
/git-notes
|
|
|
|
|
/git-p4
|
|
|
|
|
/git-pack-redundant
|
|
|
|
|
/git-pack-objects
|
|
|
|
|
/git-pack-refs
|
|
|
|
|
/git-patch-id
|
|
|
|
|
/git-prune
|
|
|
|
|
/git-prune-packed
|
|
|
|
|
/git-pull
|
|
|
|
|
/git-push
|
|
|
|
|
/git-quiltimport
|
|
|
|
|
/git-range-diff
|
|
|
|
|
/git-read-tree
|
|
|
|
|
/git-rebase
|
|
|
|
|
/git-receive-pack
|
|
|
|
|
/git-reflog
|
|
|
|
|
/git-remote
|
|
|
|
|
/git-remote-http
|
|
|
|
|
/git-remote-https
|
|
|
|
|
/git-remote-ftp
|
|
|
|
|
/git-remote-ftps
|
|
|
|
|
/git-remote-fd
|
|
|
|
|
/git-remote-ext
|
|
|
|
|
/git-repack
|
|
|
|
|
/git-replace
|
|
|
|
|
/git-request-pull
|
|
|
|
|
/git-rerere
|
|
|
|
|
/git-reset
|
|
|
|
|
/git-restore
|
|
|
|
|
/git-rev-list
|
|
|
|
|
/git-rev-parse
|
|
|
|
|
/git-revert
|
|
|
|
|
/git-rm
|
|
|
|
|
/git-send-email
|
|
|
|
|
/git-send-pack
|
|
|
|
|
/git-sh-i18n
|
|
|
|
|
/git-sh-i18n--envsubst
|
|
|
|
|
/git-sh-setup
|
|
|
|
|
/git-shell
|
|
|
|
|
/git-shortlog
|
|
|
|
|
/git-show
|
|
|
|
|
/git-show-branch
|
|
|
|
|
/git-show-index
|
|
|
|
|
/git-show-ref
|
|
|
|
|
/git-sparse-checkout
|
|
|
|
|
/git-stage
|
|
|
|
|
/git-stash
|
|
|
|
|
/git-status
|
|
|
|
|
/git-stripspace
|
|
|
|
|
/git-submodule
|
|
|
|
|
/git-submodule--helper
|
|
|
|
|
/git-subtree
|
|
|
|
|
/git-svn
|
|
|
|
|
/git-switch
|
|
|
|
|
/git-symbolic-ref
|
|
|
|
|
/git-tag
|
|
|
|
|
/git-unpack-file
|
|
|
|
|
/git-unpack-objects
|
|
|
|
|
/git-update-index
|
|
|
|
|
/git-update-ref
|
|
|
|
|
/git-update-server-info
|
|
|
|
|
/git-upload-archive
|
|
|
|
|
/git-upload-pack
|
|
|
|
|
/git-var
|
|
|
|
|
/git-verify-commit
|
|
|
|
|
/git-verify-pack
|
|
|
|
|
/git-verify-tag
|
|
|
|
|
/git-web--browse
|
|
|
|
|
/git-whatchanged
|
|
|
|
|
/git-worktree
|
|
|
|
|
/git-write-tree
|
|
|
|
|
/git-core-*/?*
|
|
|
|
|
/gitweb/GITWEB-BUILD-OPTIONS
|
|
|
|
|
/gitweb/gitweb.cgi
|
|
|
|
|
/gitweb/static/gitweb.js
|
|
|
|
|
/gitweb/static/gitweb.min.*
|
help: move list_config_help to builtin/help
Starting in 3ac68a93fd2, help.o began to depend on builtin/branch.o,
builtin/clean.o, and builtin/config.o. This meant that help.o was
unusable outside of the context of the main Git executable.
To make help.o usable by other commands again, move list_config_help()
into builtin/help.c (where it makes sense to assume other builtin libraries
are present).
When command-list.h is included but a member is not used, we start to
hear a compiler warning. Since the config list is generated in a fairly
different way than the command list, and since commands and config
options are semantically different, move the config list into its own
header and move the generator into its own script and build rule.
For reasons explained in 976aaedc (msvc: add a Makefile target to
pre-generate the Visual Studio solution, 2019-07-29), some build
artifacts we consider non-source files cannot be generated in the
Visual Studio environment, and we already have some Makefile tweaks
to help Visual Studio to use generated command-list.h header file.
Do the same to a new generated file, config-list.h, introduced by
this change.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
5 years ago
|
|
|
/config-list.h
|
|
|
|
|
/command-list.h
|
hook-list.h: add a generated list of hooks, like config-list.h
Make githooks(5) the source of truth for what hooks git supports, and
punt out early on hooks we don't know about in find_hook(). This
ensures that the documentation and the C code's idea about existing
hooks doesn't diverge.
We still have Perl and Python code running its own hooks, but that'll
be addressed by Emily Shaffer's upcoming "git hook run" command.
This resolves a long-standing TODO item in bugreport.c of there being
no centralized listing of hooks, and fixes a bug with the bugreport
listing only knowing about 1/4 of the p4 hooks. It didn't know about
the recent "reference-transaction" hook either.
We could make the find_hook() function die() or BUG() out if the new
known_hook() returned 0, but let's make it return NULL just as it does
when it can't find a hook of a known type. Making it die() is overly
anal, and unlikely to be what we need in catching stupid typos in the
name of some new hook hardcoded in git.git's sources. By making this
be tolerant of unknown hook names, changes in a later series to make
"git hook run" run arbitrary user-configured hook names will be easier
to implement.
I have not been able to directly test the CMake change being made
here. Since 4c2c38e800 (ci: modification of main.yml to use cmake for
vs-build job, 2020-06-26) some of the Windows CI has a hard dependency
on CMake, this change works there, and is to my eyes an obviously
correct use of a pattern established in previous CMake changes,
namely:
- 061c2240b1 (Introduce CMake support for configuring Git,
2020-06-12)
- 709df95b78 (help: move list_config_help to builtin/help,
2020-04-16)
- 976aaedca0 (msvc: add a Makefile target to pre-generate the Visual
Studio solution, 2019-07-29)
The LC_ALL=C is needed because at least in my locale the dash ("-") is
ignored for the purposes of sorting, which results in a different
order. I'm not aware of anything in git that has a hard dependency on
the order, but e.g. the bugreport output would end up using whatever
locale was in effect when git was compiled.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years ago
|
|
|
/hook-list.h
|
|
|
|
|
*.tar.gz
|
|
|
|
|
*.dsc
|
|
|
|
|
*.deb
|
|
|
|
|
/git.spec
|
|
|
|
|
*.exe
|
|
|
|
|
*.[aos]
|
Makefile: add support for generating JSON compilation database
Tools based on LibClang [1] can make use of a 'JSON Compilation
Database' [2] that keeps track of the exact options used to compile a set
of source files.
For example, clangd [3], which is a C language server protocol
implementation, can use a JSON compilation database to determine the
flags needed to compile a file so it can provide proper editor
integration. As a result, editors supporting the language server
protocol (such as VS Code, Emacs, or Vim, with suitable plugins) can
provide better searching, integration, and refactoring tools.
The Clang compiler can generate JSON fragments when compiling [4],
using the `-MJ` flag. These JSON fragments (one per compiled source
file) can then be concatenated to create the compilation database,
commonly called 'compile_commands.json'.
Add support to the Makefile for generating these JSON fragments as well
as the compilation database itself, if the environment variable
'GENERATE_COMPILATION_DATABASE' is set.
If this variable is set, check that $(CC) indeed supports the `-MJ`
flag, following what is done for automatic dependencies.
All JSON fragments are placed in the 'compile_commands/' directory, and
the compilation database 'compile_commands.json' is generated as a
dependency of the 'all' target using a `sed` invocation.
[1] https://clang.llvm.org/docs/Tooling.html
[2] https://clang.llvm.org/docs/JSONCompilationDatabase.html
[3] https://clangd.llvm.org/
[4] https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mj-arg
Helped-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
4 years ago
|
|
|
*.o.json
|
|
|
|
|
*.py[co]
|
|
|
|
|
.depend/
|
|
|
|
|
*.gcda
|
|
|
|
|
*.gcno
|
|
|
|
|
*.gcov
|
|
|
|
|
/coverage-untested-functions
|
|
|
|
|
/cover_db/
|
|
|
|
|
/cover_db_html/
|
|
|
|
|
*+
|
|
|
|
|
/config.mak
|
|
|
|
|
/autom4te.cache
|
|
|
|
|
/config.cache
|
|
|
|
|
/config.log
|
|
|
|
|
/config.status
|
|
|
|
|
/config.mak.autogen
|
|
|
|
|
/config.mak.append
|
|
|
|
|
/configure
|
|
|
|
|
/.vscode/
|
|
|
|
|
/tags
|
|
|
|
|
/TAGS
|
|
|
|
|
/cscope*
|
Makefile: add support for generating JSON compilation database
Tools based on LibClang [1] can make use of a 'JSON Compilation
Database' [2] that keeps track of the exact options used to compile a set
of source files.
For example, clangd [3], which is a C language server protocol
implementation, can use a JSON compilation database to determine the
flags needed to compile a file so it can provide proper editor
integration. As a result, editors supporting the language server
protocol (such as VS Code, Emacs, or Vim, with suitable plugins) can
provide better searching, integration, and refactoring tools.
The Clang compiler can generate JSON fragments when compiling [4],
using the `-MJ` flag. These JSON fragments (one per compiled source
file) can then be concatenated to create the compilation database,
commonly called 'compile_commands.json'.
Add support to the Makefile for generating these JSON fragments as well
as the compilation database itself, if the environment variable
'GENERATE_COMPILATION_DATABASE' is set.
If this variable is set, check that $(CC) indeed supports the `-MJ`
flag, following what is done for automatic dependencies.
All JSON fragments are placed in the 'compile_commands/' directory, and
the compilation database 'compile_commands.json' is generated as a
dependency of the 'all' target using a `sed` invocation.
[1] https://clang.llvm.org/docs/Tooling.html
[2] https://clang.llvm.org/docs/JSONCompilationDatabase.html
[3] https://clangd.llvm.org/
[4] https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mj-arg
Helped-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
4 years ago
|
|
|
/compile_commands.json
|
Makefile: emulate compile in $(HCO) target better
Currently, when testing headers using `make hdr-check`, headers are
directly compiled. Although this seems to test the headers, this is too
strict since we treat the headers as C sources. As a result, this will
cause warnings to appear that would otherwise not, such as a static
variable definition intended for later use throwing a unused variable
warning.
In addition, on platforms that can run `make hdr-check` but require
custom flags, this target was failing because none of them were being
passed to the compiler. For example, on MacOS, the NO_OPENSSL flag was
being set but it was not being passed into compiler so the check was
failing.
Fix these problems by emulating the compile process better, including
test compiling dummy *.hcc C sources generated from the *.h files and
passing $(ALL_CFLAGS) into the compiler for the $(HCO) target so that
these custom flags can be used.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years ago
|
|
|
*.hcc
|
|
|
|
|
*.obj
|
|
|
|
|
*.lib
|
|
|
|
|
*.res
|
|
|
|
|
*.sln
|
Makefile: make the "sparse" target non-.PHONY
Change the "sparse" target and its *.sp dependencies to be
non-.PHONY. Before this change "make sparse" would take ~5s to re-run
all the *.c files through "cgcc", after it it'll create an empty *.sp
file sitting alongside the *.c file, only if the *.c file or its
dependencies are newer than the *.sp is the *.sp re-made.
We ensure that the recursive dependencies are correct by depending on
the *.o file, which in turn will have correct dependencies by either
depending on all header files, or under
"COMPUTE_HEADER_DEPENDENCIES=yes" the headers it needs.
This means that a plain "make sparse" is much slower, as we'll now
need to make the *.o files just to create the *.sp files, but
incrementally creating the *.sp files is *much* faster and less
verbose, it thus becomes viable to run "sparse" along with "all" as
e.g. "git rebase --exec 'make all sparse'".
On my box with -j8 "make sparse" was fast before, or around 5 seconds,
now it only takes that long the first time, and the common case is
<100ms, or however long it takes GNU make to stat the *.sp file and
see that all the corresponding *.c file and its dependencies are
older.
See 0bcd9ae85d7 (sparse: Fix errors due to missing target-specific
variables, 2011-04-21) for the modern implementation of the sparse
target being changed here.
It is critical that we use -Wsparse-error here, otherwise the error
would only show up once, but we'd successfully create the empty *.sp
file, and running a second time wouldn't show the error. I'm therefore
not putting it into SPARSE_FLAGS or SP_EXTRA_FLAGS, it's not optional,
the Makefile logic won't behave properly without it.
Appending to $@ without a move is OK here because we're using the
.DELETE_ON_ERROR Makefile feature. See 7b76d6bf221 (Makefile: add and
use the ".DELETE_ON_ERROR" flag, 2021-06-29). GNU make ensures that on
error this file will be removed.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3 years ago
|
|
|
*.sp
|
|
|
|
|
*.suo
|
|
|
|
|
*.ncb
|
|
|
|
|
*.vcproj
|
|
|
|
|
*.user
|
|
|
|
|
*.idb
|
|
|
|
|
*.pdb
|
|
|
|
|
*.ilk
|
|
|
|
|
*.iobj
|
|
|
|
|
*.ipdb
|
|
|
|
|
*.dll
|
|
|
|
|
.vs/
|
|
|
|
|
Debug/
|
|
|
|
|
Release/
|
|
|
|
|
/UpgradeLog*.htm
|
|
|
|
|
/git.VC.VC.opendb
|
|
|
|
|
/git.VC.db
|
.gitignore: ignore external debug symbols from GCC on macOS
When Git is build with a "real" GCC on macOS [1], or at least with GCC
installed via Homebrew, and CFLAGS includes the '-g' option (and our
default CFLAGS does), then by default GCC writes the debug symbols
into external files under '<binary>.dSYM/' directories (e.g.
'git-daemon.dSYM/', 'git.dSYM/', etc.).
Update '.gitignore' to ignore these directories, so they don't clutter
the output of 'git status'. Furthermore, these build artifacts then
won't trigger build failures on Travis CI via b92cb86ea1 (travis-ci:
check that all build artifacts are .gitignore-d, 2017-12-31) once one
of the following patches updates our CI build scripts to use a real
GCC in the 'osx-gcc' build job.
[1] On macOS the default '/usr/bin/gcc' executable is not a real GCC,
but merely a compatibility wrapper around Clang:
$ gcc --version
Configured with: --prefix=<...>
Apple LLVM version 9.0.0 (clang-900.0.39.2)
<...>
So even though 'make CC=gcc' does indeed execute a command called
'gcc', in the end Git will be built with Clang all the same.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years ago
|
|
|
*.dSYM
|
|
|
|
|
/contrib/buildsystems/out
|
