1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-05-04 13:36:14 +02:00
git/.gitignore

245 lines
3.4 KiB
Plaintext
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 02:14:54 +02: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 20:11:42 +02: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-rebase--preserve-merges
/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 11:45:45 +02:00
/git-restore
/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
/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
*.tar.gz
*.dsc
*.deb
/git.spec
2005-09-29 08:22:02 +02: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-04 00:13:38 +02: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-04 00:13:38 +02:00
/compile_commands.json
*.hcc
*.obj
*.lib
*.res
*.sln
*.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