git/.gitignore

246 lines
3.4 KiB
Text
Raw Normal View History

/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>
2021-04-19 00:14:54 +00:00
/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-gc
/git-get-tar-commit-id
/git-grep
/git-hash-object
/git-help
/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>
2020-09-17 18:11:42 +00:00
/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
checkout: split part of it to new command 'restore' Previously the switching branch business of 'git checkout' becomes a new command 'switch'. This adds the restore command for the checking out paths path. Similar to git-switch, a new man page is added to describe what the command will become. The implementation will be updated shortly to match the man page. A couple main differences from 'git checkout <paths>': - 'restore' by default will only update worktree. This matters more when --source is specified ('checkout <tree> <paths>' updates both worktree and index). - 'restore --staged' can be used to restore the index. This command overlaps with 'git reset <paths>'. - both worktree and index could also be restored at the same time (from a tree) when both --staged and --worktree are specified. This overlaps with 'git checkout <tree> <paths>' - default source for restoring worktree and index is the index and HEAD respectively. A different (tree) source could be specified as with --source (*). - when both index and worktree are restored, --source must be specified since the default source for these two individual targets are different (**) - --no-overlay is enabled by default, if an entry is missing in the source, restoring means deleting the entry (*) I originally went with --from instead of --source. I still think --from is a better name. The short option -f however is already taken by force. And I do think short option is good to have, e.g. to write -s@ or -s@^ instead of --source=HEAD. (**) If you sit down and think about it, moving worktree's source from the index to HEAD makes sense, but nobody is really thinking it through when they type the commands. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-25 09:45:45 +00:00
/git-restore
/git-rev-list
/git-rev-parse
/git-revert
/git-rm
/git-send-email
/git-send-pack
2011-05-14 13:47:42 +00:00
/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.*
/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>
2021-09-26 19:03:29 +00:00
/hook-list.h
*.tar.gz
*.dsc
*.deb
/git.spec
2005-09-29 06:22:02 +00:00
*.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>
2020-09-03 22:13:38 +00:00
*.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>
2020-09-03 22:13:38 +00:00
/compile_commands.json
*.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>
2021-09-23 00:07:16 +00:00
*.sp
*.suo
*.ncb
*.vcproj
*.user
*.idb
*.pdb
*.ilk
*.iobj
*.ipdb
*.dll
.vs/
Debug/
Release/
/UpgradeLog*.htm
/git.VC.VC.opendb
/git.VC.db
*.dSYM
/contrib/buildsystems/out