2018-10-13 02:58:40 +02:00
|
|
|
/fuzz_corpora
|
2022-10-18 12:59:04 +02:00
|
|
|
/GIT-BUILD-DIR
|
2009-10-27 02:10:24 +01:00
|
|
|
/GIT-BUILD-OPTIONS
|
|
|
|
/GIT-CFLAGS
|
2011-06-22 12:50:56 +02:00
|
|
|
/GIT-LDFLAGS
|
2012-06-20 20:31:55 +02:00
|
|
|
/GIT-PREFIX
|
2013-11-18 23:23:11 +01:00
|
|
|
/GIT-PERL-DEFINES
|
2018-04-10 17:05:42 +02:00
|
|
|
/GIT-PERL-HEADER
|
2012-12-18 16:26:38 +01:00
|
|
|
/GIT-PYTHON-VARS
|
2012-06-20 20:32:16 +02:00
|
|
|
/GIT-SCRIPT-DEFINES
|
2022-11-01 23:35:46 +01:00
|
|
|
/GIT-SPATCH-DEFINES
|
2012-06-20 20:31:51 +02:00
|
|
|
/GIT-USER-AGENT
|
2009-10-27 02:10:24 +01:00
|
|
|
/GIT-VERSION-FILE
|
2009-12-03 06:14:05 +01:00
|
|
|
/bin-wrappers/
|
2009-10-27 02:10:24 +01:00
|
|
|
/git
|
|
|
|
/git-add
|
|
|
|
/git-am
|
|
|
|
/git-annotate
|
|
|
|
/git-apply
|
|
|
|
/git-archimport
|
|
|
|
/git-archive
|
|
|
|
/git-bisect
|
|
|
|
/git-blame
|
|
|
|
/git-branch
|
2020-04-16 23:18:04 +02:00
|
|
|
/git-bugreport
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-bundle
|
|
|
|
/git-cat-file
|
|
|
|
/git-check-attr
|
2013-01-06 17:58:13 +01:00
|
|
|
/git-check-ignore
|
2013-07-13 02:53:10 +02:00
|
|
|
/git-check-mailmap
|
2009-10-27 02:10:24 +01:00
|
|
|
/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>
2021-04-19 02:14:54 +02:00
|
|
|
/git-checkout--worker
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-checkout-index
|
|
|
|
/git-cherry
|
|
|
|
/git-cherry-pick
|
|
|
|
/git-clean
|
|
|
|
/git-clone
|
2012-04-21 06:44:32 +02:00
|
|
|
/git-column
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-commit
|
2018-04-02 22:34:18 +02:00
|
|
|
/git-commit-graph
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-commit-tree
|
|
|
|
/git-config
|
|
|
|
/git-count-objects
|
2012-06-24 13:39:59 +02:00
|
|
|
/git-credential
|
2011-12-10 11:34:14 +01:00
|
|
|
/git-credential-cache
|
|
|
|
/git-credential-cache--daemon
|
2011-12-10 11:34:44 +01:00
|
|
|
/git-credential-store
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-cvsexportcommit
|
|
|
|
/git-cvsimport
|
|
|
|
/git-cvsserver
|
|
|
|
/git-daemon
|
2022-08-12 22:10:15 +02:00
|
|
|
/git-diagnose
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-diff
|
|
|
|
/git-diff-files
|
|
|
|
/git-diff-index
|
|
|
|
/git-diff-tree
|
|
|
|
/git-difftool
|
|
|
|
/git-difftool--helper
|
|
|
|
/git-describe
|
|
|
|
/git-fast-export
|
|
|
|
/git-fast-import
|
|
|
|
/git-fetch
|
|
|
|
/git-fetch-pack
|
|
|
|
/git-filter-branch
|
|
|
|
/git-fmt-merge-msg
|
|
|
|
/git-for-each-ref
|
2020-09-11 19:49:16 +02:00
|
|
|
/git-for-each-repo
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-format-patch
|
|
|
|
/git-fsck
|
|
|
|
/git-fsck-objects
|
2022-03-25 19:02:49 +01:00
|
|
|
/git-fsmonitor--daemon
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-gc
|
|
|
|
/git-get-tar-commit-id
|
|
|
|
/git-grep
|
|
|
|
/git-hash-object
|
|
|
|
/git-help
|
2021-12-22 04:59:27 +01:00
|
|
|
/git-hook
|
2009-11-21 08:51:23 +01:00
|
|
|
/git-http-backend
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-http-fetch
|
|
|
|
/git-http-push
|
|
|
|
/git-imap-send
|
|
|
|
/git-index-pack
|
|
|
|
/git-init
|
|
|
|
/git-init-db
|
2014-10-13 20:16:29 +02:00
|
|
|
/git-interpret-trailers
|
2009-10-27 02:10:24 +01:00
|
|
|
/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>
2020-09-17 20:11:42 +02:00
|
|
|
/git-maintenance
|
2009-10-27 02:10:24 +01:00
|
|
|
/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
|
2018-07-12 21:39:20 +02:00
|
|
|
/git-multi-pack-index
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-mv
|
2018-07-12 21:39:20 +02:00
|
|
|
/git-name-rev
|
2009-11-21 08:53:55 +01:00
|
|
|
/git-notes
|
2012-04-09 02:18:00 +02:00
|
|
|
/git-p4
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-pack-redundant
|
|
|
|
/git-pack-objects
|
|
|
|
/git-pack-refs
|
|
|
|
/git-patch-id
|
|
|
|
/git-prune
|
|
|
|
/git-prune-packed
|
|
|
|
/git-pull
|
|
|
|
/git-push
|
|
|
|
/git-quiltimport
|
2018-08-13 13:33:02 +02:00
|
|
|
/git-range-diff
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-read-tree
|
|
|
|
/git-rebase
|
|
|
|
/git-receive-pack
|
|
|
|
/git-reflog
|
|
|
|
/git-remote
|
2009-12-09 16:26:34 +01:00
|
|
|
/git-remote-http
|
|
|
|
/git-remote-https
|
|
|
|
/git-remote-ftp
|
|
|
|
/git-remote-ftps
|
2010-10-12 18:39:42 +02:00
|
|
|
/git-remote-fd
|
2010-10-12 18:39:43 +02:00
|
|
|
/git-remote-ext
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-repack
|
|
|
|
/git-replace
|
|
|
|
/git-request-pull
|
|
|
|
/git-rerere
|
|
|
|
/git-reset
|
2019-04-25 11:45:45 +02:00
|
|
|
/git-restore
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-rev-list
|
|
|
|
/git-rev-parse
|
|
|
|
/git-revert
|
|
|
|
/git-rm
|
|
|
|
/git-send-email
|
|
|
|
/git-send-pack
|
2011-05-14 15:47:42 +02:00
|
|
|
/git-sh-i18n
|
|
|
|
/git-sh-i18n--envsubst
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-sh-setup
|
|
|
|
/git-shell
|
|
|
|
/git-shortlog
|
|
|
|
/git-show
|
|
|
|
/git-show-branch
|
|
|
|
/git-show-index
|
|
|
|
/git-show-ref
|
2019-11-21 23:04:33 +01:00
|
|
|
/git-sparse-checkout
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-stage
|
|
|
|
/git-stash
|
|
|
|
/git-status
|
|
|
|
/git-stripspace
|
|
|
|
/git-submodule
|
2015-09-02 23:42:24 +02:00
|
|
|
/git-submodule--helper
|
2021-04-27 23:17:19 +02:00
|
|
|
/git-subtree
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-svn
|
2019-03-29 11:39:05 +01:00
|
|
|
/git-switch
|
2009-10-27 02:10:24 +01:00
|
|
|
/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
|
2014-07-15 15:40:24 +02:00
|
|
|
/git-verify-commit
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-verify-pack
|
|
|
|
/git-verify-tag
|
2022-09-20 02:19:55 +02:00
|
|
|
/git-version
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-web--browse
|
|
|
|
/git-whatchanged
|
2015-06-29 14:51:18 +02:00
|
|
|
/git-worktree
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-write-tree
|
scalar: include in standard Git build & installation
Move 'scalar' out of 'contrib/' and into the root of the Git tree. The goal
of this change is to build 'scalar' as part of the standard Git build &
install processes.
This patch includes both the physical move of Scalar's files out of
'contrib/' ('scalar.c', 'scalar.txt', and 't9xxx-scalar.sh'), and the
changes to the build definitions in 'Makefile' and 'CMakelists.txt' to
accommodate the new program.
At a high level, Scalar is built so that:
- there is a 'scalar-objs' target (similar to those created in 029bac01a8
(Makefile: add {program,xdiff,test,git,fuzz}-objs & objects targets,
2021-02-23)) for debugging purposes.
- it appears in the root of the install directory (rather than the
gitexecdir).
- it is included in the 'bin-wrappers/' directory for use in tests.
- it receives a platform-specific executable suffix (e.g., '.exe'), if
applicable.
- 'scalar.txt' is installed as 'man1' documentation.
- the 'clean' target removes the 'scalar' executable.
Additionally, update the root level '.gitignore' file to ignore the Scalar
executable.
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-09-02 17:56:43 +02:00
|
|
|
/scalar
|
2009-10-27 02:10:24 +01:00
|
|
|
/git-core-*/?*
|
2022-07-05 15:46:56 +02:00
|
|
|
/git.res
|
2010-04-25 22:17:05 +02:00
|
|
|
/gitweb/GITWEB-BUILD-OPTIONS
|
2009-10-27 02:10:24 +01:00
|
|
|
/gitweb/gitweb.cgi
|
2011-04-28 21:04:01 +02:00
|
|
|
/gitweb/static/gitweb.js
|
2010-08-21 18:18:37 +02:00
|
|
|
/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>
2020-04-16 23:18:03 +02:00
|
|
|
/config-list.h
|
2018-05-10 10:46:41 +02:00
|
|
|
/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>
2021-09-26 21:03:29 +02:00
|
|
|
/hook-list.h
|
2005-09-24 20:19:07 +02:00
|
|
|
*.tar.gz
|
|
|
|
*.dsc
|
|
|
|
*.deb
|
2009-10-27 02:10:24 +01:00
|
|
|
/git.spec
|
2005-09-29 08:22:02 +02:00
|
|
|
*.exe
|
2007-05-30 19:42:41 +02:00
|
|
|
*.[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>
2020-09-04 00:13:38 +02:00
|
|
|
*.o.json
|
2006-01-05 17:38:58 +01:00
|
|
|
*.py[co]
|
Makefile: have "make pot" not "reset --hard"
Before commit fc0fd5b23b (Makefile: help gettext tools to cope with our
custom PRItime format, 2017-07-20), we'd consider source files as-is
with gettext, but because we need to understand PRItime in the same way
that gettext itself understands PRIuMAX, we'd first check if we had a
clean checkout, then munge all of the processed files in-place with
"sed", generate "po/git.pot", and then finally "reset --hard" to undo
our changes.
By generating "pot" snippets in ".build/pot/po" for each source file
and rewriting certain source files with PRItime macros to temporary
files in ".build/pot/po", we can avoid running "make pot" by altering
files in place and doing a "reset --hard" afterwards.
This speed of "make pot" is slower than before on an initial run,
because we run "xgettext" many times (once per source file), but it
can be boosted by parallelization. It is *much* faster for incremental
runs, and will allow us to implement related targets in subsequent
commits.
When the "pot" target was originally added in cd5513a7168 (i18n:
Makefile: "pot" target to extract messages marked for translation,
2011-02-22) it behaved like a "normal" target. I.e. we'd skip the
re-generation of the po/git.pot if nothing had to be done.
Then after po/git.pot was checked in in dce37b66fb0 (l10n: initial
git.pot for 1.7.10 upcoming release, 2012-02-13) the target was broken
until 1f31963e921 (i18n: treat "make pot" as an explicitly-invoked
target, 2014-08-22) when it was made to depend on "FORCE". I.e. the
Makefile's dependency resolution inherently can't handle incremental
building when the target file may be updated by git (or something else
external to "make"). But this case no longer applies, so FORCE is no
longer needed.
That out of the way, the main logic change here is getting rid of the
"reset --hard":
We'll generate intermediate ".build/pot/po/%.po" files from "%", which
is handy to see at a glance what strings (if any) in a given file are
marked for translation:
$ make .build/pot/po/pretty.c.po
[...]
$ cat .build/pot/po/pretty.c.po
#: pretty.c:1051
msgid "unable to parse --pretty format"
msgstr ""
$
For these C source files which contain the PRItime macros, we will
create temporary munged "*.c" files in a tree in ".build/pot/po"
corresponding to our source tree, and have "xgettext" consider those.
The rule needs to be careful to "(cd .build/pot/po && ...)", because
otherwise the comments in the po/git.pot file wouldn't refer to the
correct source locations (they'd be prefixed with ".build/pot/po").
These temporary munged "*.c” files will be removed immediately after
the corresponding po files are generated, because some development tools
cannot ignore the duplicate source files in the ".build" directory
according to the ".gitignore" file, and that may cause trouble.
The output of the generated po/git.pot file is changed in one minor
way: Because we're using msgcat(1) instead of xgettext(1) to
concatenate the output we'll now disambiguate where "TRANSLATORS"
comments come from, in cases where a message is the same in N files,
and either only one has a "TRANSLATORS" comment, or they're
different. E.g. for the "Your edited hunk[...]" message we'll now
apply this change (comment content elided):
+#. #-#-#-#-# add-patch.c.po #-#-#-#-#
#. TRANSLATORS: do not translate [y/n]
[...]
+#. #-#-#-#-# git-add--interactive.perl.po #-#-#-#-#
#. TRANSLATORS: do not translate [y/n]
[...]
#: add-patch.c:1253 git-add--interactive.perl:1244
msgid ""
"Your edited hunk does not apply. Edit again (saying \"no\" discards!) [y/n]? "
msgstr ""
There are six such changes, and they all make the context more
understandable, as msgcat(1) is better at handling these edge cases
than xgettext(1)'s previously used "--join-existing" flag.
But filenames in the above disambiguation lines of extracted-comments
have an extra ".po" extension compared to the filenames at the file
locations. While we could rename the intermediate ".build/pot/po/%.po"
files without the ".po" extension to use more intuitive filenames in
the disambiguation lines of extracted-comments, but that will confuse
developer tools with lots of invalid C or other source files in
".build/pot/po" directory.
The addition of "--omit-header" option for xgettext makes the "pot"
snippets in ".build/pot/po/*.po" smaller. But as we'll see in a
subsequent commit this header behavior has been hiding an
encoding-related bug from us, so let's carry it forward instead of
re-generating it with xgettext(1).
The "po/git.pot" file should have a header entry, because a proper
header entry will increase the speed of creating a new po file using
msginit and set a proper "POT-Creation-Date:" field in the header
entry of a "po/XX.po" file. We use xgettext to generate a separate
header file at ".build/pot/git.header" from "/dev/null", and use this
header to assemble "po/git.pot".
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-26 16:50:28 +02:00
|
|
|
.build/
|
2010-04-15 09:35:20 +02:00
|
|
|
.depend/
|
2010-07-25 21:52:39 +02:00
|
|
|
*.gcda
|
|
|
|
*.gcno
|
|
|
|
*.gcov
|
|
|
|
/coverage-untested-functions
|
2010-07-25 21:52:42 +02:00
|
|
|
/cover_db/
|
2010-07-25 21:52:43 +02:00
|
|
|
/cover_db_html/
|
2009-11-08 23:07:16 +01:00
|
|
|
*+
|
2009-10-27 02:10:24 +01:00
|
|
|
/config.mak
|
|
|
|
/autom4te.cache
|
|
|
|
/config.cache
|
|
|
|
/config.log
|
|
|
|
/config.status
|
|
|
|
/config.mak.autogen
|
|
|
|
/config.mak.append
|
|
|
|
/configure
|
2018-07-30 17:42:46 +02:00
|
|
|
/.vscode/
|
2009-10-27 02:10:24 +01:00
|
|
|
/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>
2020-09-04 00:13:38 +02:00
|
|
|
/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>
2019-09-25 10:21:01 +02:00
|
|
|
*.hcc
|
2009-09-16 10:20:30 +02:00
|
|
|
*.obj
|
|
|
|
*.lib
|
|
|
|
*.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>
2021-09-23 02:07:16 +02:00
|
|
|
*.sp
|
2009-09-16 10:20:30 +02:00
|
|
|
*.suo
|
|
|
|
*.ncb
|
|
|
|
*.vcproj
|
|
|
|
*.user
|
|
|
|
*.idb
|
|
|
|
*.pdb
|
2019-06-25 16:49:42 +02:00
|
|
|
*.ilk
|
|
|
|
*.iobj
|
|
|
|
*.ipdb
|
|
|
|
*.dll
|
|
|
|
.vs/
|
2019-07-29 22:08:14 +02:00
|
|
|
Debug/
|
|
|
|
Release/
|
2019-07-29 22:08:15 +02:00
|
|
|
/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>
2019-01-17 02:29:10 +01:00
|
|
|
*.dSYM
|
2020-09-25 16:28:29 +02:00
|
|
|
/contrib/buildsystems/out
|