https://github.com/git/git

sort by:
Revision Author Date Message Commit Date
fba8e4c git-repack.txt: remove spurious ")" Drop the ")" at the end of this paragraph. There's a parenthetical remark in this paragraph, but it's been closed on the line above. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 May 2021, 05:12:47 UTC
2d677e5 The fourteenth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 May 2021, 03:47:42 UTC
39c5392 Merge branch 'll/clone-reject-shallow' Fix tests when forced to use v0 protocol. * ll/clone-reject-shallow: t5601: mark protocol v2-only test 07 May 2021, 03:47:42 UTC
70a890d Merge branch 'si/zsh-complete-comment-fix' Portability fix for command line completion script (in contrib/). * si/zsh-complete-comment-fix: work around zsh comment in __git_complete_worktree_paths 07 May 2021, 03:47:42 UTC
18e1ba1 Merge branch 'dl/complete-stash-updates' Further update the command line completion (in contrib/) for "git stash". * dl/complete-stash-updates: git-completion.bash: consolidate cases in _git_stash() git-completion.bash: use $__git_cmd_idx in more places git-completion.bash: rename to $__git_cmd_idx git-completion.bash: separate some commands onto their own line 07 May 2021, 03:47:41 UTC
848a17c Merge branch 'dl/complete-stash' The command line completion (in contrib/) for "git stash" has been updated. * dl/complete-stash: git-completion.bash: use __gitcomp_builtin() in _git_stash() git-completion.bash: extract from else in _git_stash() git-completion.bash: pass $__git_subcommand_idx from __git_main() 07 May 2021, 03:47:41 UTC
936e588 Merge branch 'ah/plugleaks' Plug various leans reported by LSAN. * ah/plugleaks: builtin/rm: avoid leaking pathspec and seen builtin/rebase: release git_format_patch_opt too builtin/for-each-ref: free filter and UNLEAK sorting. mailinfo: also free strbuf lists when clearing mailinfo builtin/checkout: clear pending objects after diffing builtin/check-ignore: clear_pathspec before returning builtin/bugreport: don't leak prefixed filename branch: FREE_AND_NULL instead of NULL'ing real_ref bloom: clear each bloom_key after use ls-files: free max_prefix when done wt-status: fix multiple small leaks revision: free remainder of old commit list in limit_list 07 May 2021, 03:47:41 UTC
8585d6c Merge branch 'ps/rev-list-object-type-filter' "git rev-list" learns the "--filter=object:type=<type>" option, which can be used to exclude objects of the given kind from the packfile generated by pack-objects. * ps/rev-list-object-type-filter: rev-list: allow filtering of provided items pack-bitmap: implement combined filter pack-bitmap: implement object type filter list-objects: implement object type filter list-objects: support filtering by tag and commit list-objects: move tag processing into its own function revision: mark commit parents as NOT_USER_GIVEN uploadpack.txt: document implication of `uploadpackfilter.allow` 07 May 2021, 03:47:41 UTC
826ef0e Merge branch 'ab/svn-tests-set-e-fix' Test clean-up. * ab/svn-tests-set-e-fix: svn tests: refactor away a "set -e" in test body svn tests: remove legacy re-setup from init-clone test 07 May 2021, 03:47:40 UTC
0377ac9 Merge branch 'ab/rebase-no-reschedule-failed-exec' "git rebase --[no-]reschedule-failed-exec" did not work well with its configuration variable, which has been corrected. * ab/rebase-no-reschedule-failed-exec: rebase: don't override --no-reschedule-failed-exec with config rebase tests: camel-case rebase.rescheduleFailedExec consistently 07 May 2021, 03:47:40 UTC
5a357fa Merge branch 'ab/doc-lint' Dev support. * ab/doc-lint: docs: fix linting issues due to incorrect relative section order doc lint: lint relative section order doc lint: lint and fix missing "GIT" end sections doc lint: fix bugs in, simplify and improve lint script doc lint: Perl "strict" and "warnings" in lint-gitlink.perl Documentation/Makefile: make doc.dep dependencies a variable again Documentation/Makefile: make $(wildcard howto/*.txt) a var 07 May 2021, 03:47:40 UTC
fe069dc Merge branch 'mt/add-rm-in-sparse-checkout' "git add" and "git rm" learned not to touch those paths that are outside of sparse checkout. * mt/add-rm-in-sparse-checkout: rm: honor sparse checkout patterns add: warn when asked to update SKIP_WORKTREE entries refresh_index(): add flag to ignore SKIP_WORKTREE entries pathspec: allow to ignore SKIP_WORKTREE entries on index matching add: make --chmod and --renormalize honor sparse checkouts t3705: add tests for `git add` in sparse checkouts add: include magic part of pathspec on --refresh error 07 May 2021, 03:47:40 UTC
e706aaf Merge branch 'ps/config-global-override' Replace GIT_CONFIG_NOSYSTEM mechanism to decline from reading the system-wide configuration file with GIT_CONFIG_SYSTEM that lets users specify from which file to read the system-wide configuration (setting it to an empty file would essentially be the same as setting NOSYSTEM), and introduce GIT_CONFIG_GLOBAL to override the per-user configuration in $HOME/.gitconfig. * ps/config-global-override: t1300: fix unset of GIT_CONFIG_NOSYSTEM leaking into subsequent tests config: allow overriding of global and system configuration config: unify code paths to get global config paths config: rename `git_etc_config()` 07 May 2021, 03:47:39 UTC
f16a466 Merge branch 'zh/pretty-date-human' "git log --format=..." placeholders learned %ah/%ch placeholders to request the --date=human output. * zh/pretty-date-human: pretty: provide human date format 07 May 2021, 03:47:39 UTC
c108c8c Merge branch 'zh/format-ref-array-optim' "git (branch|tag) --format=..." has been micro-optimized. * zh/format-ref-array-optim: ref-filter: reuse output buffer ref-filter: get rid of show_ref_array_item 07 May 2021, 03:47:39 UTC
bb2feec Merge branch 'ad/cygwin-no-backslashes-in-paths' Cygwin pathname handling fix. * ad/cygwin-no-backslashes-in-paths: cygwin: disallow backslashes in file names 07 May 2021, 03:47:39 UTC
6d99f31 Merge branch 'jz/apply-3way-first-message-fix' When we swapped the order of --3way fallback, we forgot to adjust the message we give when the first method fails and the second method is attempted (which used to be "direct application failed hence we try 3way", now it is the other way around). * jz/apply-3way-first-message-fix: apply: adjust messages to account for --3way changes 07 May 2021, 03:47:38 UTC
6e08cbd Merge branch 'jk/prune-with-bitmap-fix' When the reachability bitmap is in effect, the "do not lose recently created objects and those that are reachable from them" safety to protect us from races were disabled by mistake, which has been corrected. * jk/prune-with-bitmap-fix: prune: save reachable-from-recent objects with bitmaps pack-bitmap: clean up include_check after use 07 May 2021, 03:47:38 UTC
e60e9cc Merge branch 'po/diff-patch-doc' Doc update. * po/diff-patch-doc: doc: point to diff attribute in patch format docs 07 May 2021, 03:47:38 UTC
a850356 Merge branch 'hn/trace-reflog-expiry' The reflog expiry machinery has been taught to emit trace events. * hn/trace-reflog-expiry: refs/debug: trace into reflog expiry too 07 May 2021, 03:47:38 UTC
e5d99d3 Merge branch 'ab/pretty-date-format-tests' Tweak a few tests for "log --format=..." that show timestamps in various formats. * ab/pretty-date-format-tests: pretty tests: give --date/format tests a better description pretty tests: simplify %aI/%cI date format test 07 May 2021, 03:47:38 UTC
5f586f5 Merge branch 'ps/config-env-option-with-separate-value' "git --config-env var=val cmd" weren't accepted (only --config-env=var=val was). * ps/config-env-option-with-separate-value: git: support separate arg for `--config-env`'s value git.txt: fix synopsis of `--config-env` missing the equals sign 07 May 2021, 03:47:37 UTC
3a7f090 clean: remove unnecessary variable The variable `matches` used to hold the return of a `dir_path_match()` call that was removed in 95c11ecc73 ("Fix error-prone fill_directory() API; make it only return matches", 2020-04-01). Now `matches` will always hold 0, which is the value it's initialized with; and the condition `matches != MATCHED_EXACTLY` will always evaluate to true. So let's remove this unnecessary variable. Interestingly, it seems that `matches != MATCHED_EXACTLY` was already unnecessary before 95c11ecc73. That's because `remove_directories` is always set to 1 when we have pathspecs; So, in the condition `!remove_directories && matches != MATCHED_EXACTLY`, we would either: - have pathspecs (or have been given `-d`) and ignore `matches` because `remove_directories` is 1; or - not have pathspecs (nor `-d`) and end up just checking that `0 != MATCHED_EXACTLY`, as `matches` would never get reassigned after its zero initialization (because there is no pathspec to match). Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 22:48:11 UTC
dd9323b mailinfo: stop parsing options manually In a later change, mailinfo will learn more options, let's switch to our robust parse_options framework before that step. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 21:40:26 UTC
d582992 mailinfo: load default metainfo_charset lazily In a later change, we will use parse_option to parse mailinfo's options. In mailinfo, both "-u", "-n", and "--encoding" try to set the same field, with "-u" reset that field to some default value from configuration variable "i18n.commitEncoding". Let's delay the setting of that field until we finish processing all options. By doing that, "i18n.commitEncoding" can be parsed on demand. More importantly, it cleans the way for using parse_option. This change introduces some inconsistent brackets "{}" in "if/else if" construct, however, we will rewrite them in the next few changes. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 21:40:25 UTC
a1989cf add: die if both --dry-run and --interactive are given The interactive machinery does not obey --dry-run. Die appropriately if both flags are passed. Signed-off-by: Øystein Walle <oystwa@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 21:14:04 UTC
256c2dc perl: use mock i18n functions under NO_GETTEXT=Y Change the logic of the i18n functions I added in 5e9637c6297 (i18n: add infrastructure for translating Git with gettext, 2011-11-18) to use pass-through functions when NO_GETTEXT is defined. This speeds up the compilation time of commands that use this library when NO_GETTEXT=Y is in effect. Loading it and POSIX.pm is around 20ms on my machine, whereas it takes 2ms to just instantiate perl itself. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 03:58:33 UTC
368a50d Makefile: regenerate *.pm on NO_PERL_CPAN_FALLBACKS change Regenerate the *.pm files in perl/build/* if the NO_PERL_CPAN_FALLBACKS flag added to the *.pm files in 1aca69c0195 (perl Git::LoadCPAN: emit better errors under NO_PERL_CPAN_FALLBACKS, 2018-03-03) is changed. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 03:58:32 UTC
3d49f72 Makefile: regenerate perl/build/* if GIT-PERL-DEFINES changes Change the logic to generate perl/build/* to regenerate those files if GIT-PERL-DEFINES changes. This ensures that e.g. changing localedir will result in correctly re-generated files. I don't think that ever worked. The brokenness pre-dates my 20d2a30f8ff (Makefile: replace perl/Makefile.PL with simple make rules, 2017-12-10). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 03:58:30 UTC
4070c9e Makefile: don't re-define PERL_DEFINES Since 07d90eadb50 (Makefile: add Perl runtime prefix support, 2018-04-10) we have been declaring PERL_DEFINES right after assigning to it, with the effect that the first PERL_DEFINES was ignored. That bug didn't matter in practice since the first line had all the same variables as the second, so we'd correctly re-generate everything. It just made for confusing reading. Let's remove that first assignment, and while we're at it split these across lines to make them more maintainable. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 03:58:27 UTC
d4e2d15 streaming.c: move {open,close,read} from vtable to "struct git_istream" Move the definition of the structure around the open/close/read functions introduced in 46bf043807c (streaming: a new API to read from the object store, 2011-05-11) to instead populate "close" and "read" members in the "struct git_istream". This gets us rid of an extra pointer deference, and I think makes more sense. The "close" and "read" functions are the primary interface to the stream itself. Let's also populate a "open" callback in the same struct. That's now used by open_istream() after istream_source() decides what "open" function should be used. This isn't needed to get rid of the "stream_vtbl" variables, but makes sense for consistency. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 03:56:10 UTC
de94c0e streaming.c: stop passing around "object_info *" to open() Change the streaming interface to stop passing around the "struct object_info" the open() functions. As seen in 7ef2d9a2604 (streaming: read non-delta incrementally from a pack, 2011-05-13) which introduced the "st->u.in_pack" assignments being changed here only the open_istream_pack_non_delta() path need these. So let's instead do this when preparing the selected callback in the istream_source() function. This might also allow the compiler to reduce the lifetime of the "oi" variable, as we've moved it from "git_istream()" to "istream_source()". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 03:56:09 UTC
bc062ad streaming.c: remove {open,close,read}_method_decl() macros Remove the {open,close,read}_method_decl() macros added in 46bf043807c (streaming: a new API to read from the object store, 2011-05-11) in favor of inlining the definition of the arguments of these functions. Since we'll end up using them via the "{open,close,read}_istream_fn" types we don't gain anything in the way of compiler checking by using these macros, and as of preceding commits we no longer need to declare these argument lists twice. So declaring them at a distance just serves to make the code less readable. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 03:56:06 UTC
0d9af06 streaming.c: remove enum/function/vtbl indirection Remove the indirection of discovering a function pointer to use via an enum and virtual table. This refactors code added in 46bf043807c (streaming: a new API to read from the object store, 2011-05-11). We can instead simply return an "open_istream_fn" for use from the "istream_source()" selector function directly. This allows us to get rid of the "incore", "loose" and "pack_non_delta" enum variables. We'll return the functions instead. The "stream_error" variable in that enum can likewise go in favor of returning NULL, which is what the open_istream() was doing when it got that value anyway. We can thus remove the entire enum, and the "open_istream_tbl" virtual table that (indirectly) referenced it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 03:56:04 UTC
b655283 streaming.c: avoid forward declarations Change code added in 46bf043807c (streaming: a new API to read from the object store, 2011-05-11) to avoid forward declarations of the functions it uses. We can instead move this code to the bottom of the file, and thus avoid the open_method_decl() calls. Aside from the addition of the "static helpers[...]" comment being added here, and the removal of the forward declarations this is a move-only change. The style of the added "static helpers[...]" comment isn't in line with our usual coding style, but is consistent with several other comments used in this file, so let's use that style consistently here. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 03:56:02 UTC
b79f9c0 sparse-index.c: remove set_index_sparse_config() Remove the set_index_sparse_config() function by folding it into set_sparse_index_config(), which was its only user. Since 122ba1f7b52 (sparse-checkout: toggle sparse index from builtin, 2021-03-30) the flow of this code hasn't made much sense, we'd get "enabled" in set_sparse_index_config(), proceed to call set_index_sparse_config() with it. There we'd call prepare_repo_settings() and set "repo->settings.sparse_index = 1", only to needlessly call prepare_repo_settings() again in set_sparse_index_config() (where it would early abort), and finally setting "repo->settings.sparse_index = enabled". Instead we can just call prepare_repo_settings() once, and set the variable to "enabled" in the first place. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 03:53:46 UTC
6b79818 git-p4: speed up search for branch parent For every new branch that git-p4 imports, it needs to find the commit where it branched off its parent branch. While p4 doesn't record this information explicitly, the first changelist on a branch is usually an identical copy of the parent branch. The method searchParent() tries to find a commit in the history of the given "parent" branch whose tree exactly matches the initial changelist of the new branch, "target". The code iterates through the parent commits and compares each of them to this initial changelist using diff-tree. Since we already know the tree object name we are looking for, spawning diff-tree for each commit is wasteful. Use the "--format" option of "rev-list" to find out the tree object name of each commit in the history, and find the tree whose name is exactly the same as the tree of the target commit to optimize this. This results in a considerable speed-up, at least on Windows. On one Windows machine with a fairly large repository of about 16000 commits in the parent branch, the current code takes over 7 minutes, while the new code only takes just over 10 seconds for the same changelist: Before: $ time git p4 sync Importing from/into multiple branches Depot paths: //depot Importing revision 31274 (100.0%) Updated branches: b1 real 7m41.458s user 0m0.000s sys 0m0.077s After: $ time git p4 sync Importing from/into multiple branches Depot paths: //depot Importing revision 31274 (100.0%) Updated branches: b1 real 0m10.235s user 0m0.000s sys 0m0.062s Signed-off-by: Joachim Kuebart <joachim.kuebart@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 03:51:33 UTC
c3ab088 git-p4: ensure complex branches are cloned correctly When importing a branch from p4, git-p4 searches the history of the parent branch for the branch point. The test for the complex branch structure ensures all files have the expected contents, but doesn't examine the branch structure. Check for the correct branch structure by making sure that the initial commit on each branch is empty. This ensures that the initial commit's parent is indeed the correct branch-off point. Signed-off-by: Joachim Kuebart <joachim.kuebart@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 May 2021, 03:51:31 UTC
f91371b patience diff: remove unused variable Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2021, 09:56:48 UTC
204aa2d patience diff: remove unnecessary string comparisons xdl_prepare_env() calls xdl_classify_record() which arranges for the hashes of non-matching lines to be different so lines can be tested for equality by comparing just their hashes. This reduces the time taken to calculate the diff of v2.28.0 to v2.29.0 by ~3-4%. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2021, 09:56:48 UTC
0324e8f word diff: handle zero length matches If find_word_boundaries() encounters a zero length match (which can be caused by matching a newline or using '*' instead of '+' in the regex) we stop splitting the input into words which generates an inaccurate diff. To fix this increment the start point when there is a zero length match and try a new match. This is safe as posix regular expressions always return the longest available match so a zero length match means there are no longer matches available from the current position. Commit bf82940dbf1 (color-words: enable REG_NEWLINE to help user, 2009-01-17) prevented matching newlines in negated character classes but it is still possible for the user to have an explicit newline match in the regex which could cause a zero length match. One could argue that having explicit newline matches or using '*' rather than '+' are user errors but it seems to be better to work round them than produce inaccurate diffs. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2021, 09:53:42 UTC
87094fc ci: run test round with parallel-checkout enabled We already have tests for the basic parallel-checkout operations. But this code can also run be executed by other commands, such as git-read-tree and git-sparse-checkout, which are currently not tested with multiple workers. To promote a wider test coverage without duplicating tests: 1. Add the GIT_TEST_CHECKOUT_WORKERS environment variable, to optionally force parallel-checkout execution during the whole test suite. 2. Set this variable (with a value of 2) in the second test round of our linux-gcc CI job. This round runs `make test` again with some optional GIT_TEST_* variables enabled, so there is no additional overhead in exercising the parallel-checkout code here. Note that tests checking out less than two parallel-eligible entries will fall back to the sequential mode. Nevertheless, it's still a good exercise for the parallel-checkout framework as the fallback codepath also writes the queued entries using the parallel-checkout functions (only without spawning any worker). Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2021, 03:27:17 UTC
d0e5d35 parallel-checkout: add tests for basic operations Add tests to populate the working tree during clone and checkout using sequential and parallel mode, to confirm that they produce identical results. Also test basic checkout mechanics, such as checking for symlinks in the leading directories and the abidance to --force. Note: some helper functions are added to a common lib file which is only included by t2080 for now. But they will also be used by other parallel-checkout tests in the following patches. 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> 05 May 2021, 03:26:36 UTC
70b052b checkout-index: add parallel checkout support Allow checkout-index to use the parallel checkout framework, honoring the checkout.workers configuration. There are two code paths in checkout-index which call `checkout_entry()`, and thus, can make use of parallel checkout: `checkout_file()`, which is used to write paths explicitly given at the command line; and `checkout_all()`, which is used to write all paths in the index, when the `--all` option is given. In both operation modes, checkout-index doesn't abort immediately on a `checkout_entry()` failure. Instead, it tries to check out all remaining paths before exiting with a non-zero exit code. To keep this behavior when parallel checkout is being used, we must allow `run_parallel_checkout()` to try writing the queued entries before we exit, even if we already got an error code from a previous `checkout_entry()` call. However, `checkout_all()` doesn't return on errors, it calls `exit()` with code 128. We could make it call `run_parallel_checkout()` before exiting, but it makes the code easier to follow if we unify the exit path for both checkout-index modes at `cmd_checkout_index()`, and let this function take care of the interactions with the parallel checkout API. So let's do that. With this change, we also have to consider whether we want to keep using 128 as the error code for `git checkout-index --all`, while we use 1 for `git checkout-index <path>` (even when the actual error is the same). Since there is not much value in having code 128 only for `--all`, and there is no mention about it in the docs (so it's unlikely that changing it will break any existing script), let's make both modes exit with code 1 on `checkout_entry()` errors. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2021, 03:26:36 UTC
d590422 parallel-checkout: add tests related to .gitattributes Add tests to confirm that the `struct conv_attrs` data is correctly passed from the main process to the workers, and that they can properly convert the blobs before writing them to the working tree. Also check that parallel-ineligible entries, such as regular files that require external filters, are correctly smudge and written when parallel-checkout is enabled. 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> 05 May 2021, 03:26:36 UTC
2fa3cba t0028: extract encoding helpers to lib-encoding.sh The following patch will add tests outside t0028 which will also need to re-encode some strings. Extract the auxiliary encoding functions from t0028 to a common lib file so that they can be reused. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2021, 03:26:36 UTC
6a7bc9d parallel-checkout: add tests related to path collisions Add tests to confirm that path collisions are properly detected by checkout workers, both to avoid race conditions and to report colliding entries on clone. 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> 05 May 2021, 03:26:36 UTC
6053950 builtin/checkout.c: complete parallel checkout support Pathspec-limited checkouts (like `git checkout *.txt`) are performed by a code path that doesn't yet support parallel checkout because it calls checkout_entry() directly, instead of unpack_trees(). Let's add parallel checkout support for this code path too. The transient cache entries allocated in checkout_merged() are now allocated in a mem_pool which is only discarded after parallel checkout finishes. This is done because the entries need to be valid when run_parallel_checkout() is called. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2021, 03:26:33 UTC
9616882 make_transient_cache_entry(): optionally alloc from mem_pool Allow make_transient_cache_entry() to optionally receive a mem_pool struct in which it should allocate the entry. This will be used in the following patch, to store some transient entries which should persist until parallel checkout finishes. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2021, 03:25:25 UTC
b89c731 t5601: mark protocol v2-only test A HTTP-clone test introduced in 4fe788b1b0 ("builtin/clone.c: add --reject-shallow option", 2021-04-01) only works in protocol v2, but is not marked as such. The aforementioned patch implements --reject-shallow for a variety of situations, but usage of a protocol that requires a remote helper is not one of them. (Such an implementation would require extending the remote helper protocol to support the passing of a "reject shallow" option, and then teaching it to both protocol-speaking ends.) For now, to make it pass when GIT_TEST_PROTOCOL_VERSION=0 is passed, add "-c protocol.version=2". A more complete solution would be either to augment the remote helper protocol to support this feature or to return a fatal error when using --reject-shallow with a protocol that uses a remote helper. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2021, 01:54:41 UTC
477673d send-pack: support push negotiation Teach Git the push.negotiate config variable. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2021, 01:41:29 UTC
9c1e657 fetch: teach independent negotiation (no packfile) Currently, the packfile negotiation step within a Git fetch cannot be done independent of sending the packfile, even though there is at least one application wherein this is useful. Therefore, make it possible for this negotiation step to be done independently. A subsequent commit will use this for one such application - push negotiation. This feature is for protocol v2 only. (An implementation for protocol v0 would require a separate implementation in the fetch, transport, and transport helper code.) In the protocol, the main hindrance towards independent negotiation is that the server can unilaterally decide to send the packfile. This is solved by a "wait-for-done" argument: the server will then wait for the client to say "done". In practice, the client will never say it; instead it will cease requests once it is satisfied. In the client, the main change lies in the transport and transport helper code. fetch_refs_via_pack() performs everything needed - protocol version and capability checks, and the negotiation itself. There are 2 code paths that do not go through fetch_refs_via_pack() that needed to be individually excluded: the bundle transport (excluded through requiring smart_options, which the bundle transport doesn't support) and transport helpers that do not support takeover. If or when we support independent negotiation for protocol v0, we will need to modify these 2 code paths to support it. But for now, report failure if independent negotiation is requested in these cases. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2021, 01:41:29 UTC
f2acf76 work around zsh comment in __git_complete_worktree_paths [PATCH]: contrib/completion/git-completion.bash, there is a construct where comment lines are placed between the command that is on the upstream of a pipe and the command that is on the downstream of a pipe in __git_complete_worktree_paths function. Unfortunately, this script is also used by Zsh completion, but Zsh mishandles this construct when "interactive_comments" option is not set (by default it is off on macOS), resulting in a breakage: $ git worktree remove [TAB] $ git worktree remove __git_complete_worktree_paths:7: command not found: # Move the comment, even though it explains what happens on the downstream of the pipe and logically belongs where it is right now, before the entire pipeline, to work around this problem. Signed-off-by: Sardorbek Imomaliev <sardorbek.imomaliev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 May 2021, 03:17:23 UTC
c364b7e trailer: add new .cmd config option The `trailer.<token>.command` configuration variable specifies a command (run via the shell, so it does not have to be a single name or path to the command, but can be a shell script), and the first occurrence of substring $ARG is replaced with the value given to the `interpret-trailer` command for the token in a '--trailer <token>=<value>' argument. This has three downsides: * The use of $ARG in the mechanism misleads the users that the value is passed in the shell variable, and tempt them to use $ARG more than once, but that would not work, as the second and subsequent $ARG are not replaced. * Because $ARG is textually replaced without regard to the shell language syntax, even '$ARG' (inside a single-quote pair), which a user would expect to stay intact, would be replaced, and worse, if the value had an unmatched single quote (imagine a name like "O'Connor", substituted into NAME='$ARG' to make it NAME='O'Connor'), it would result in a broken command that is not syntactically correct (or worse). * The first occurrence of substring `$ARG` will be replaced with the empty string, in the command when the command is first called to add a trailer with the specified <token>. This is a bad design, the nature of automatic execution causes it to add a trailer that we don't expect. Introduce a new `trailer.<token>.cmd` configuration that takes higher precedence to deprecate and eventually remove `trailer.<token>.command`, which passes the value as an argument to the command. Instead of "$ARG", users can refer to the value as positional argument, $1, in their scripts. At the same time, in order to allow `git interpret-trailers` to better simulate the behavior of `git command -s`, 'trailer.<token>.cmd' will not automatically execute. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Christian Couder <christian.couder@gmail.com> Signed-off-by: ZheNing Hu <adlternative@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 May 2021, 03:09:43 UTC
57dcb65 docs: correct descript of trailer.<token>.command In the original documentation of `trailer.<token>.command`, some descriptions are easily misunderstood. So let's modify it to increase its readability. In addition, clarify that `$ARG` in command can only be replaced once. Signed-off-by: ZheNing Hu <adlternative@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 May 2021, 03:09:43 UTC
8ff06de docs: document symlink restrictions for dot-files We stopped allowing symlinks for .gitmodules files in 10ecfa7649 (verify_path: disallow symlinks in .gitmodules, 2018-05-04), and we stopped following symlinks for .gitattributes, .gitignore, and .mailmap in the commits from 204333b015 (Merge branch 'jk/open-dotgitx-with-nofollow', 2021-03-22). The reasons are discussed in detail there, but we never adjusted the documentation to let users know. This hasn't been a big deal since the point is that such setups were mildly broken and thought to be unusual anyway. But it certainly doesn't hurt to be clear and explicit about it. Suggested-by: Philip Oakley <philipoakley@iee.email> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 May 2021, 02:52:03 UTC
bb6832d fsck: warn about symlinked dotfiles we'll open with O_NOFOLLOW In the commits merged in via 204333b015 (Merge branch 'jk/open-dotgitx-with-nofollow', 2021-03-22), we stopped following symbolic links for .gitattributes, .gitignore, and .mailmap files. Let's teach fsck to warn that these symlinks are not going to do anything. Note that this is just a warning, and won't block the objects via transfer.fsckObjects, since there are reported to be cases of this in the wild (and even once fixed, they will continue to exist in the commit history of those projects, but are not particularly dangerous). Note that we won't add these to the existing gitmodules block in the fsck code. The logic for gitmodules is a bit more complicated, as we also check the content of non-symlink instances we find. But for these new files, there is no content check; we're just looking at the name and mode of the tree entry (and we can avoid even the complicated name checks in the common case that the mode doesn't indicate a symlink). We can reuse the test helper function we defined for .gitmodules, though (it needs some slight adjustments for the fsck error code, and because we don't block these symlinks via verify_path()). Note that I didn't explicitly test the transfer.fsckObjects case here (nor does the existing .gitmodules test that it blocks a push). The translation of fsck severities to outcomes is covered in general in t5504. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 May 2021, 02:52:02 UTC
801ed01 t0060: test ntfs/hfs-obscured dotfiles We have tests that cover various filesystem-specific spellings of ".gitmodules", because we need to reliably identify that path for some security checks. These are from dc2d9ba318 (is_{hfs,ntfs}_dotgitmodules: add tests, 2018-05-12), with the actual code coming from e7cb0b4455 (is_ntfs_dotgit: match other .git files, 2018-05-11) and 0fc333ba20 (is_hfs_dotgit: match other .git files, 2018-05-02). Those latter two commits also added similar matching functions for .gitattributes and .gitignore. These ended up not being used in the final series, and are currently dead code. But in preparation for them being used in some fsck checks, let's make sure they actually work by throwing a few basic tests at them. Likewise, let's cover .mailmap (which does need matching code added). I didn't bother with the whole battery of tests that we cover for .gitmodules. These functions are all based on the same generic matcher, so it's sufficient to test most of the corner cases just once. Note that the ntfs magic prefix names in the tests come from the algorithm described in e7cb0b4455 (and are different for each file). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 May 2021, 02:52:02 UTC
1cb12f3 t7450: test .gitmodules symlink matching against obscured names In t7450 we check that both verify_path() and fsck catch malformed .gitmodules entries in trees. However, we don't check that we catch filesystem-equivalent forms of these (e.g., ".GITMOD~1" on Windows). Our name-matching functions are exercised well in t0060, but there's nothing to test that we correctly call the matching functions from the actual fsck and verify_path() code. So instead of testing just .gitmodules, let's repeat our tests for a few basic cases. We don't need to be exhaustive here (t0060 handles that), but just make sure we hit one name of each type. Besides pushing the tests into a function that takes the path as a parameter, we'll need to do a few things: - adjust the directory name to accommodate the tests running multiple times - set core.protecthfs for index checks. Fsck always protects all types by default, but we want to be able to exercise the HFS routines on every system. Note that core.protectntfs is already the default these days, but it doesn't hurt to explicitly label our need for it. - we'll also take the filename ("gitmodules") as a parameter. All calls use the same name for now, but a future patch will extend this to handle other .gitfoo files. Note that our fake-content symlink destination is somewhat .gitmodules specific. But it isn't necessary for other files (which don't do a content check). And it happens to be a valid attribute and ignore file anyway. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 May 2021, 02:52:02 UTC
a1ca398 t7450: test verify_path() handling of gitmodules Commit 10ecfa7649 (verify_path: disallow symlinks in .gitmodules, 2018-05-04) made it impossible to load a symlink .gitmodules file into the index. However, there are no tests of this behavior. Let's make sure this case is covered. We can easily reuse the test setup created by the matching b7b1fca175 (fsck: complain when .gitmodules is a symlink, 2018-05-04). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 May 2021, 02:52:02 UTC
43a2220 t7415: rename to expand scope This script has already expanded beyond its original intent of ".. in submodule names" to include other malicious submodule bits. Let's update the name and description to reflect that, as well as the fact that we'll soon be adding similar tests for other dotfiles (.gitattributes, etc). We'll also renumber it to move it out of the group of submodule-specific tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 05:41:08 UTC
0282f67 fsck_tree(): wrap some long lines Many calls to report() in fsck_tree() are kept on a single line and are quite long. Most were pretty big to begin with, but have gotten even longer over the years as we've added more parameters. Let's accept the churn of wrapping them in order to conform to our usual line limits. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 05:41:08 UTC
9e1947c fsck_tree(): fix shadowed variable Commit b2f2039c2b (fsck: accept an oid instead of a "struct tree" for fsck_tree(), 2019-10-18) introduced a new "oid" parameter to fsck_tree(), and we pass it to the report() function when we find problems. However, that is shadowed within the tree-walking loop by the existing "oid" variable which we use to store the oid of each tree entry. As a result, we may report the wrong oid for some problems we detect within the loop (the entry oid, instead of the tree oid). Our tests didn't catch this because they checked only that we found the expected fsck problem, not that it was attached to the correct object. Let's rename both variables in the function to avoid confusion. This makes the diff a little noisy (e.g., all of the report() calls outside the loop were already correct but need to be touched), but makes sure we catch all cases and will avoid similar confusion in the future. And we can update the test to be a bit more specific and catch this problem. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 05:41:08 UTC
963d02a t7415: remove out-dated comment about translation Since GETTEXT_POISON does not exist anymore, there is no point warning people about whether we should use test_i18ngrep. This is doubly confusing because the comment was describing why it was OK to use grep, but it got caught up in the mass conversion of 674ba34038 (fsck: mark strings for translation, 2018-11-10). Note there are other uses of test_i18ngrep in this script which are now obsolete; I'll save those for a mass-cleanup. My goal here was just to fix the confusing comment in code I'm about to refactor. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 05:41:08 UTC
8e0601f docs/format-patch: mention handling of merges Format-patch doesn't have a way to format merges in a way that can be applied by git-am (or any other tool), and so it just omits them. However, this may be a surprising implication for users who are not well versed in how the tool works. Let's add a note to the documentation making this more clear. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 05:32:39 UTC
6d52b6a pack-objects: clamp negative depth to 0 A negative delta depth makes no sense, and the code is not prepared to handle it. If passed "--depth=-1" on the command line, then this line from break_delta_chains(): cur->depth = (total_depth--) % (depth + 1); triggers a divide-by-zero. This is undefined behavior according to the C standard, but on POSIX systems results in SIGFPE killing the process. This is certainly one way to inform the use that the command was invalid, but it's a bit friendlier to just treat it as "don't allow any deltas", which we already do for --depth=0. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 05:30:46 UTC
49ac1d3 t5316: check behavior of pack-objects --depth=0 We'd expect this to cleanly produce no deltas at all (as opposed to getting confused by an out-of-bounds value), and it does. Note we have to adjust our max_chain test helper, which expected to find at least one delta. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 05:29:56 UTC
953aa54 pack-objects: clamp negative window size to 0 A negative window size makes no sense, and the code in find_deltas() is not prepared to handle it. If you pass "-1", for example, we end up generate a 0-length array of "struct unpacked", but our loop assumes it has at least one entry in it (and we end up reading garbage memory). We could complain to the user about this, but it's more forgiving to just clamp it to 0, which means "do not find any deltas at all". The 0-case is already tested earlier in the script, so we'll make sure this does the same thing. Reported-by: Yiyuan guo <yguoaz@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 05:29:27 UTC
9535678 t5300: check that we produced expected number of deltas We pack a set of objects both with and without --window=0, assuming that the 0-length window will cause us not to produce any deltas. Let's confirm that this is the case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 05:29:16 UTC
5489899 t5300: modernize basic tests The first set of tests in t5300 goes back to 2005, and doesn't use some of our customary style and tools these days. In preparation for touching them, let's modernize a few things: - titles go on the line with test_expect_success, with a hanging open-quote to start the test body - test bodies should be indented with tabs - opening braces for shell blocks in &&-chains go on their own line - no space between redirect operators and files (">foo", not "> foo") - avoid doing work outside of test blocks; in this case, we can stick the setup of ".git2" into the appropriate blocks - avoid modifying and then cleaning up the environment or current directory by using subshells and "git -C" - this test does a curious thing when testing the unpacking: it sets GIT_OBJECT_DIRECTORY, and then does a "git init" in the _original_ directory, creating a weird mixed situation. Instead, it's much simpler to just "git init --bare" a new repository to unpack into, and check the results there. I renamed this "git2" instead of ".git2" to make it more clear it's a separate repo. - we can observe that the bodies of the no-delta, ref_delta, and ofs_delta cases are all virtually identical except for the pack creation, and factor out shared helper functions. I collapsed "do the unpack" and "check the results of the unpack" into a single test, since that makes the expected lifetime of the "git2" temporary directory more clear (that also lets us use test_when_finished to clean it up). This does make the "-v" output slightly less useful, but the improvement in reading the actual test code makes it worth it. - I dropped the "pwd" calls from some tests. These don't do anything functional, and I suspect may have been an aid for debugging when the script was more cavalier about leaving the working directory changed between tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 05:29:16 UTC
a84fd3b CodingGuidelines: explicitly allow "local" for test scripts 01d3a526 (t0000: check whether the shell supports the "local" keyword, 2017-10-26) raised a test balloon to see if those who build and test Git use a platform with a shell that lacks support for the "local" keyword. After two years, 7f0b5908 (t0000: reword comments for "local" test, 2019-08-08) documented that "local" keyword, even though is outside POSIX, is allowed in our test scripts. Let's write it in the CodingGuidelines, too. It might be tempting to allow it in scripted Porcelains (we have avoided getting them contaminiated by "local" so far), but they are on their way out and getting rewritten in C. Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 05:24:11 UTC
ad9322d merge: fix swapped "up to date" message components The rewrite of git-merge from shell to C in 1c7b76be7d (Build in merge, 2008-07-07) accidentally transformed the message: Already up-to-date. (nothing to squash) to: (nothing to squash)Already up-to-date. due to reversed printf() arguments. This problem has gone unnoticed despite being touched over the years by 7f87aff22c (Teach/Fix pull/fetch -q/-v options, 2008-11-15) and bacec47845 (i18n: git-merge basic messages, 2011-02-22), and tangentially by bef4830e88 (i18n: merge: mark messages for translation, 2016-06-17) and 7560f547e6 (treewide: correct several "up-to-date" to "up to date", 2017-08-23). Fix it by restoring the message to its intended order. While at it, help translators out by avoiding "sentence Lego". [es: rewrote commit message] Co-authored-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Josh Soref <jsoref@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 05:14:58 UTC
80cde95 merge(s): apply consistent punctuation to "up to date" messages Although the various "Already up to date" messages resulting from merge attempts share identical phrasing, they use a mix of punctuation ranging from "." to "!" and even "Yeeah!", which leads to extra work for translators. Ease the job of translators by settling upon "." as punctuation for all such messages. While at it, take advantage of printf_ln() to further ease the translation task so translators need not worry about line termination, and fix a case of missing line termination in the (unused) merge_ort_nonrecursive() function. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 05:14:56 UTC
62af4bd submodule update: silence underlying fetch with "--quiet" Commands such as $ git submodule update --quiet --init --depth=1 involving shallow clones, call the shell function fetch_in_submodule, which in turn invokes git fetch. Pass the --quiet option onward there. Signed-off-by: Nicholas Clark <nick@ccl4.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 May 2021, 03:24:38 UTC
7e39198 The thirteenth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 April 2021, 04:50:27 UTC
93e0b28 Merge branch 'ab/pathname-encoding-doc' Clarify that pathnames recorded in Git trees are most often (but not necessarily) encoded in UTF-8. * ab/pathname-encoding-doc: doc: clarify the filename encoding in git diff 30 April 2021, 04:50:27 UTC
5980e0d Merge branch 'vs/completion-with-set-u' Effort to make the command line completion (in contrib/) safe with "set -u" continues. * vs/completion-with-set-u: completion: avoid aliased command lookup error in nounset mode 30 April 2021, 04:50:27 UTC
bf0d4c8 Merge branch 'hn/refs-trace-errno' Show errno in the trace output in the error codepath that calls read_raw_ref method. * hn/refs-trace-errno: refs: print errno for read_raw_ref if GIT_TRACE_REFS is set 30 April 2021, 04:50:27 UTC
a1cac26 Merge branch 'mt/parallel-checkout-part-2' The checkout machinery has been taught to perform the actual write-out of the files in parallel when able. * mt/parallel-checkout-part-2: parallel-checkout: add design documentation parallel-checkout: support progress displaying parallel-checkout: add configuration options parallel-checkout: make it truly parallel unpack-trees: add basic support for parallel checkout 30 April 2021, 04:50:26 UTC
59bb0aa Merge branch 'so/log-diff-merge' "git log" learned "--diff-merges=<style>" option, with an associated configuration variable log.diffMerges. * so/log-diff-merge: doc/diff-options: document new --diff-merges features diff-merges: introduce log.diffMerges config variable diff-merges: adapt -m to enable default diff format diff-merges: refactor set_diff_merges() diff-merges: introduce --diff-merges=on 30 April 2021, 04:50:26 UTC
8e97852 Merge branch 'ds/sparse-index-protections' Builds on top of the sparse-index infrastructure to mark operations that are not ready to mark with the sparse index, causing them to fall back on fully-populated index that they always have worked with. * ds/sparse-index-protections: (47 commits) name-hash: use expand_to_path() sparse-index: expand_to_path() name-hash: don't add directories to name_hash revision: ensure full index resolve-undo: ensure full index read-cache: ensure full index pathspec: ensure full index merge-recursive: ensure full index entry: ensure full index dir: ensure full index update-index: ensure full index stash: ensure full index rm: ensure full index merge-index: ensure full index ls-files: ensure full index grep: ensure full index fsck: ensure full index difftool: ensure full index commit: ensure full index checkout: ensure full index ... 30 April 2021, 04:50:26 UTC
d250f90 Merge branch 'ds/maintenance-prefetch-fix' The prefetch task in "git maintenance" assumed that "git fetch" from any remote would fetch all its local branches, which would fetch too much if the user is interested in only a subset of branches there. * ds/maintenance-prefetch-fix: maintenance: respect remote.*.skipFetchAll maintenance: use 'git fetch --prefetch' fetch: add --prefetch option maintenance: simplify prefetch logic 30 April 2021, 04:50:25 UTC
a819e2b Merge branch 'ow/push-quiet-set-upstream' "git push --quiet --set-upstream" was not quiet when setting the upstream branch configuration, which has been corrected. * ow/push-quiet-set-upstream: transport: respect verbosity when setting upstream 30 April 2021, 04:50:25 UTC
279a2e6 Merge branch 'mt/pkt-write-errors' When packet_write() fails, we gave an extra error message unnecessarily, which has been corrected. * mt/pkt-write-errors: pkt-line: do not report packet write errors twice 30 April 2021, 04:50:24 UTC
13158b9 Merge branch 'jk/promisor-optim' Handling of "promisor packs" that allows certain objects to be missing and lazily retrievable has been optimized (a bit). * jk/promisor-optim: revision: avoid parsing with --exclude-promisor-objects lookup_unknown_object(): take a repository argument is_promisor_object(): free tree buffer after parsing 30 April 2021, 04:50:24 UTC
4cd66e7 bisect--helper: use BISECT_TERMS in 'bisect skip' command Commit e4c7b33747 ("bisect--helper: reimplement `bisect_skip` shell function in C", 2021-02-03), as part of the shell-to-C conversion, forgot to read the 'terms' file (.git/BISECT_TERMS) during the new 'bisect skip' command implementation. As a result, the 'bisect skip' command will use the default 'bad'/'good' terms. If the bisection terms have been set to non-default values (for example by the 'bisect start' command), then the 'bisect skip' command will fail. In order to correct this problem, we insert a call to the get_terms() function, which reads the non-default terms from that file (if set), in the '--bisect-skip' command implementation of 'bisect--helper'. Also, add a test[1] to protect against potential future regression. [1] https://lore.kernel.org/git/xmqqim45h585.fsf@gitster.g/T/#m207791568054b0f8cf1a3942878ea36293273c7d Reported-by: Trygve Aaberge <trygveaa@gmail.com> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 April 2021, 00:56:42 UTC
bccc37f cygwin: disallow backslashes in file names The backslash character is not a valid part of a file name on Windows. If, in Windows, Git attempts to write a file that has a backslash character in the filename, it will be incorrectly interpreted as a directory separator. This caused CVE-2019-1354 in MinGW, as this behaviour can be manipulated to cause the checkout to write to files it ought not write to, such as adding code to the .git/hooks directory. This was fixed by e1d911dd4c (mingw: disallow backslash characters in tree objects' file names, 2019-09-12). However, the vulnerability also exists in Cygwin: while Cygwin mostly provides a POSIX-like path system, it will still interpret a backslash as a directory separator. To avoid this vulnerability, CVE-2021-29468, extend the previous fix to also apply to Cygwin. Similarly, extend the test case added by the previous version of the commit. The test suite doesn't have an easy way to say "run this test if in MinGW or Cygwin", so add a new test prerequisite that covers both. As well as checking behaviour in the presence of paths containing backslashes, the existing test also checks behaviour in the presence of paths that differ only by the presence of a trailing ".". MinGW follows normal Windows application behaviour and treats them as the same path, but Cygwin more closely emulates *nix systems (at the expense of compatibility with native Windows applications) and will create and distinguish between such paths. Gate the relevant bit of that test accordingly. Reported-by: RyotaK <security@ryotak.me> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 April 2021, 00:49:20 UTC
c331551 git: support separate arg for `--config-env`'s value While not documented as such, many of the top-level options like `--git-dir` and `--work-tree` support two syntaxes: they accept both an equals sign between option and its value, and they do support option and value as two separate arguments. The recently added `--config-env` option only supports the syntax with an equals sign. Mitigate this inconsistency by accepting both syntaxes and add tests to verify both work. Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 April 2021, 00:46:53 UTC
9152904 git.txt: fix synopsis of `--config-env` missing the equals sign When executing `git -h`, then the `--config-env` documentation rightly lists the option as requiring an equals between the option and its argument: this is the only currently supported format. But the git(1) manpage incorrectly lists the option as taking a space in between. Fix the issue by adding the missing space. Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-of-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 April 2021, 00:46:46 UTC
526705f apply: adjust messages to account for --3way changes "git apply" specifically calls out when it is falling back to 3way merge application. Since the order changed to preferring 3way and falling back to direct application, continue that behavior by printing whenever 3way fails and git has to fall back. Signed-off-by: Jerry Zhang <jerry@skydio.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 April 2021, 03:27:45 UTC
2ba582b prune: save reachable-from-recent objects with bitmaps We pass our prune expiration to mark_reachable_objects(), which will traverse not only the reachable objects, but consider any recent ones as tips for reachability; see d3038d22f9 (prune: keep objects reachable from recent objects, 2014-10-15) for details. However, this interacts badly with the bitmap code path added in fde67d6896 (prune: use bitmaps for reachability traversal, 2019-02-13). If we hit the bitmap-optimized path, we return immediately to avoid the regular traversal, accidentally skipping the "also traverse recent" code. Instead, we should do an if-else for the bitmap versus regular traversal, and then follow up with the "recent" traversal in either case. This reuses the "rev_info" for a bitmap and then a regular traversal, but that should work OK (the bitmap code clears the pending array in the usual way, just like a regular traversal would). Note that I dropped the comment above the regular traversal here. It has little explanatory value, and makes the if-else logic much harder to read. Here are a few variants that I rejected: - it seems like both the reachability and recent traversals could be done in a single traversal. This was rejected by d3038d22f9 (prune: keep objects reachable from recent objects, 2014-10-15), though the balance may be different when using bitmaps. However, there's a subtle correctness issue, too: we use revs->ignore_missing_links for the recent traversal, but not the reachability one. - we could try using bitmaps for the recent traversal, too, which could possibly improve performance. But it would require some fixes in the bitmap code, which uses ignore_missing_links for its own purposes. Plus it would probably not help all that much in practice. We use the reachable tips to generate bitmaps, so those objects are likely not covered by bitmaps (unless they just became unreachable). And in general, we expect the set of unreachable objects to be much smaller anyway, so there's less to gain. The test in t5304 detects the bug and confirms the fix. I also beefed up the tests in t6501, which covers the mtime-checking code more thoroughly, to handle the bitmap case (in addition to just "loose" and "packed" cases). Interestingly, this test doesn't actually detect the bug, because it is running "git gc", and not "prune" directly. And "gc" will call "repack" first, which does not suffer the same bug. So the old-but-reachable-from-recent objects get scooped up into the new pack along with the actually-recent objects, which gives both a recent mtime. But it seemed prudent to get more coverage of the bitmap case for related code. Reported-by: David Emett <dave@sp4m.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 April 2021, 01:38:25 UTC
1e951c6 pack-bitmap: clean up include_check after use When a bitmap walk has to traverse (to fill in non-bitmapped objects), we use rev_info's include_check mechanism to let us stop the traversal early. But after setting the function and its data parameter, we never clean it up. This means that if the rev_info is used for a subsequent traversal without bitmaps, it will unexpectedly call into our include_check function (worse, it will do so pointing to a now-defunct stack variable in include_check_data, likely resulting in a segfault). There's no code which does this now, but it's an accident waiting to happen. Let's clean up after ourselves in the bitmap code. Reported-by: David Emett <dave@sp4m.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 April 2021, 01:03:46 UTC
9a3e3ca subtree: be stricter about validating flags Don't silently ignore a flag that's invalid for a given subcommand. The user expected it to do something; we should tell the user that they are mistaken, instead of surprising the user. It could be argued that this change might break existing users. I'd argue that those existing users are already broken, and they just don't know it. Let them know that they're broken. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 April 2021, 07:47:19 UTC
49470cd subtree: push: allow specifying a local rev other than HEAD 'git subtree split' lets you specify a rev other than HEAD. 'git push' lets you specify a mapping between a local thing and a remot ref. So smash those together, and have 'git subtree push' let you specify which local thing to run split on and push the result of that split to the remote ref. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 April 2021, 07:47:19 UTC
94389e7 subtree: allow 'split' flags to be passed to 'push' 'push' does a 'split' internally, but it doesn't pass flags through to the 'split'. This is silly, if you need to pass flags to 'split', then it means that you can't use 'push'! So, have 'push' accept 'split' flags, and pass them through to 'split'. Add tests for this by copying split's tests with minimal modification. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 April 2021, 07:47:19 UTC
cb65514 subtree: allow --squash to be used with --rejoin Besides being a genuinely useful thing to do, this also just makes sense and harmonizes which flags may be used when. `git subtree split --rejoin` amounts to "automatically go ahead and do a `git subtree merge` after doing the main `git subtree split`", so it's weird and arbitrary that you can't pass `--squash` to `git subtree split --rejoin` like you can `git subtree merge`. It's weird that `git subtree split --rejoin` inherits `git subtree merge`'s `--message` but not `--squash`. Reconcile the situation by just having `split --rejoin` actually just call `merge` internally (or call `add` instead, as appropriate), so it can get access to the full `merge` behavior, including `--squash`. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 April 2021, 07:47:19 UTC
6468784 subtree: give the docs a once-over Just went through the docs looking for anything inaccurate or that can be improved. In the '-h' text, in the man page synopsis, and in the man page description: Normalize the ordering of the list of sub-commands: 'add', 'merge', 'split', 'pull', 'push'. This allows us to kinda separate the lower-level add/merge/split from the higher-level pull/push. '-h' text: - correction: Indicate that split's arg is optional. - clarity: Emphasize that 'pull' takes the 'add'/'merge' flags. man page: - correction: State that all subcommands take options (it seemed to indicate that only 'split' takes any options other than '-P'). - correction: 'split' only guarantees that the results are identical if the flags are identical. - correction: The flag is named '--ignore-joins', not '--ignore-join'. - completeness: Clarify that 'push' always operates on HEAD, and that 'split' operates on HEAD if no local commit is given. - clarity: In the description, when listing commands, repeat what their arguments are. This way the reader doesn't need to flip back and forth between the command description and the synopsis and the full description to understand what's being said. - clarity: In the <variables> used to give command arguments, give slightly longer, descriptive names. Like <local-commit> instead of just <commit>. - clarity: Emphasize that 'pull' takes the 'add'/'merge' flags. - style: In the synopsis, list options before the subcommand. This makes things line up and be much more readable when shown non-monospace (such as in `make html`), and also more closely matches other man pages (like `git-submodule.txt`). - style: Use the correct syntax for indicating the options ([<options>] instead of [OPTIONS]). - style: In the synopsis, separate 'pull' and 'push' from the other lower-level commands. I think this helps readability. - style: Code-quote things in prose that seem like they should be code-quoted, like '.gitmodules', flags, or full commands. - style: Minor wording improvements, like more consistent mood (many of the command descriptions start in the imperative mood and switch to the indicative mode by the end). That sort of thing. - style: Capitalize "ID". - style: Remove the "This option is only valid for XXX command" remarks from each option, and instead rely on the section headings. - style: Since that line is getting edited anyway, switch "behaviour" to American "behavior". - style: Trim trailing whitespace. `todo`: - style: Trim trailing whitespace. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 April 2021, 07:47:19 UTC
e9525a8 subtree: have $indent actually affect indentation Currently, the $indent variable is just used to track how deeply we're nested, and the debug log is indented by things like debug " foo" That is: The indentation-level is hard-coded. It used to be that the code couldn't recurse, so the indentation level could be known statically, so it made sense to just hard-code it in the output. However, since 315a84f9aa ("subtree: use commits before rejoins for splits", 2018-09-28), it can now recurse, and the debug log is misleading. So fix that. Indent according to $indent. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 April 2021, 07:47:18 UTC
534ff90 subtree: don't let debug and progress output clash Currently, debug output (triggered by passing '-d') and progress output stomp on each other. The debug output is just streamed as lines to stderr, and the progress output is sent to stderr as '%s\r'. When writing to a file, it is awkward to read and difficult to distinguish between the debug output and a progress line. When writing to a terminal the debug lines hide progress lines. So, when '-d' has been passed, spit out progress as 'progress: %s\n', instead of as '%s\r', so that it can be detected, and so that the debug lines don't overwrite the progress when written to a terminal. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 April 2021, 07:47:18 UTC
5cdae0f subtree: add comments and sanity checks For each function in subtree, add a usage comment saying what the arguments are, and add an `assert` checking the number of arguments. In figuring out each thing's arguments in order to write those comments and assertions, it turns out that find_existing_splits is written as if it takes multiple 'revs', but it is in fact only ever passed a single 'rev': unrevs="$(find_existing_splits "$dir" "$rev")" || exit $? So go ahead and codify that by documenting and asserting that it takes exactly two arguments, one dir and one rev. Signed-off-by: Luke Shumaker <lukeshu@datawire.io> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 April 2021, 07:47:18 UTC
back to top