summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2022-02-25object API: rename hash_object_file_literally() to write_*()Libravatar Ævar Arnfjörð Bjarmason1-1/+1
Before 0c3db67cc81 (hash-object --literally: fix buffer overrun with extra-long object type, 2015-05-04) the hash-object code being changed here called write_sha1_file() to both hash and write a loose object. Before that we'd use hash_sha1_file() to if "-w" wasn't provided, and otherwise call write_sha1_file(). Now we'll always call the same function for both writing. Let's rename it from hash_*_literally() to write_*_literally(). Even though the write_*() might not actually write if HASH_WRITE_OBJECT isn't in "flags", having it be more similar to write_object_file_flags() than hash_object_file(), but carrying a name that would suggest that it's a variant of the latter is confusing. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object-file API: split up and simplify check_object_signature()Libravatar Ævar Arnfjörð Bjarmason3-5/+4
Split up the check_object_signature() function into that non-streaming version (it accepts an already filled "buf"), and a new stream_object_signature() which will retrieve the object from storage, and hash it on-the-fly. All of the callers of check_object_signature() were effectively calling two different functions, if we go by cyclomatic complexity. I.e. they'd either take the early "if (map)" branch and return early, or not. This has been the case since the "if (map)" condition was added in 090ea12671b (parse_object: avoid putting whole blob in core, 2012-03-07). We can then further simplify the resulting check_object_signature() function since only one caller wanted to pass a non-NULL "buf" and a non-NULL "real_oidp". That "read_loose_object()" codepath used by "git fsck" can instead use hash_object_file() followed by oideq(). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object API users + docs: check <0, not !0 with check_object_signature()Libravatar Ævar Arnfjörð Bjarmason2-4/+3
Change those users of the object API that misused check_object_signature() by assuming it returned any non-zero when the OID didn't match the expected value to check <0 instead. In practice all of this code worked before, but it wasn't consistent with rest of the users of the API. Let's also clarify what the <0 return value means in API docs. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object-file API: have write_object_file() take "enum object_type"Libravatar Ævar Arnfjörð Bjarmason8-10/+10
Change the write_object_file() function to take an "enum object_type" instead of a "const char *type". Its callers either passed {commit,tree,blob,tag}_type and can pass the corresponding OBJ_* type instead, or were hardcoding strings like "blob". This avoids the back & forth fragility where the callers of write_object_file() would have the enum type, and convert it themselves via type_name(). We do have to now do that conversion ourselves before calling write_object_file_prepare(), but those codepaths will be similarly adjusted in subsequent commits. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-25object-file API: add a format_object_header() functionLibravatar Ævar Arnfjörð Bjarmason2-5/+4
Add a convenience function to wrap the xsnprintf() command that generates loose object headers. This code was copy/pasted in various parts of the codebase, let's define it in one place and re-use it from there. All except one caller of it had a valid "enum object_type" for us, it's only write_object_file_prepare() which might need to deal with "git hash-object --literally" and a potential garbage type. Let's have the primary API use an "enum object_type", and define a *_literally() function that can take an arbitrary "const char *" for the type. See [1] for the discussion that prompted this patch, i.e. new code in object-file.c that wanted to copy/paste the xsnprintf() invocation. In the case of fast-import.c the callers unfortunately need to cast back & forth between "unsigned char *" and "char *", since format_object_header() ad encode_in_pack_object_header() take different signedness. 1. https://lore.kernel.org/git/211213.86bl1l9bfz.gmgdl@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-26Merge branch 'en/keep-cwd'Libravatar Junio C Hamano1-1/+5
Fix a regression in 2.35 that roke the use of "rebase" and "stash" in a secondary worktree. * en/keep-cwd: sequencer, stash: fix running from worktree subdir
2022-01-26sequencer, stash: fix running from worktree subdirLibravatar Elijah Newren1-1/+5
In commits bc3ae46b42 ("rebase: do not attempt to remove startup_info->original_cwd", 2021-12-09) and 0fce211ccc ("stash: do not attempt to remove startup_info->original_cwd", 2021-12-09), we wanted to allow the subprocess to know which directory the parent process was running from, so that the subprocess could protect it. However... When run from a non-main worktree, setup_git_directory() will note that the discovered git directory (/PATH/TO/.git/worktree/non-main-worktree) does not match DEFAULT_GIT_DIR_ENVIRONMENT (see setup_discovered_git_dir()), and decide to set GIT_DIR in the environment. This matters because... Whenever git is run with the GIT_DIR environment variable set, and GIT_WORK_TREE not set, it presumes that '.' is the working tree. So... This combination results in the subcommand being very confused about the working tree. Fix it by also setting the GIT_WORK_TREE environment variable along with setting cmd.dir. A possibly more involved fix we could consider for later would be to make setup.c set GIT_WORK_TREE whenever (a) it discovers both the git directory and the working tree and (b) it decides to set GIT_DIR in the environment. I did not attempt that here as such would be too big of a change for a 2.35.1 release. Test-case-by: Glen Choo <chooglen@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-24Merge branch 'ab/checkout-branch-info-leakfix'Libravatar Junio C Hamano1-3/+0
We added an unrelated sanity checking that leads to a BUG() while plugging a leak, which triggered in a repository with symrefs in the local branch namespace that point at a ref outside. Partially revert the change to avoid triggering the BUG(). * ab/checkout-branch-info-leakfix: checkout: avoid BUG() when hitting a broken repository
2022-01-21checkout: avoid BUG() when hitting a broken repositoryLibravatar Junio C Hamano1-3/+0
When 9081a421 (checkout: fix "branch info" memory leaks, 2021-11-16) cleaned up existing memory leaks, we added an unrelated sanity check to ensure that a local branch is truly local and not a symref to elsewhere that dies with BUG() otherwise. This was misguided in two ways. First of all, such a tightening did not belong to a leak-fix patch. And the condition it detected was *not* a bug in our program but a problem in user data, where warning() or die() would have been more appropriate. As the condition is not fatal (the result of computing the local branch name in the code that is involved in the faulty check is only used as a textual label for the commit), let's revert the code to the original state, i.e. strip "refs/heads/" to compute the local branch name if possible, and otherwise leave it NULL. The consumer of the information in merge_working_tree() is prepared to see NULL in there and act accordingly. cf. https://bugzilla.redhat.com/show_bug.cgi?id=2042920 Reported-by: Petr Šplíchal <psplicha@redhat.com> Reported-by: Todd Zullinger <tmz@pobox.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-20Merge branch 'js/branch-track-inherit'Libravatar Junio C Hamano2-2/+2
"git branch -h" incorrectly said "--track[=direct|inherit]", implying that "--trackinherit" is a valid option, which has been corrected. source: <3de40324bea6a1dd9bca2654721471e3809e87d8.1642538935.git.steadmon@google.com> source: <c3c26192-aee9-185a-e559-b8735139e49c@web.de> * js/branch-track-inherit: branch,checkout: fix --track documentation
2022-01-20branch,checkout: fix --track documentationLibravatar René Scharfe2-2/+2
Document that the accepted variants of the --track option are --track, --track=direct, and --track=inherit. The equal sign in the latter two cannot be replaced with whitespace; in general optional arguments need to be attached firmly to their option. Put "direct" consistently before "inherit", if only for the reasons that the former is the default, explained first in the documentation, and comes before the latter alphabetically. Mention both modes in the short help so that readers don't have to look them up in the full documentation. They are literal strings and thus untranslatable. PARSE_OPT_LITERAL_ARGHELP is inferred due to the pipe and parenthesis characters, so we don't have to provide that flag explicitly. Mention that -t has the same effect as --track and --track=direct. There is no way to specify inherit mode using the short option, because short options generally don't accept optional arguments. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-18Merge branch 'js/branch-track-inherit'Libravatar Junio C Hamano2-5/+5
"git branch -h" incorrectly said "--track[=direct|inherit]", implying that "--trackinherit" is a valid option, which has been corrected. * js/branch-track-inherit: branch,checkout: fix --track usage strings
2022-01-18branch,checkout: fix --track usage stringsLibravatar Josh Steadmon2-5/+5
As Ævar pointed out in [1], the use of PARSE_OPT_LITERAL_ARGHELP with a list of allowed parameters is not recommended. Both git-branch and git-checkout were changed in d311566 (branch: add flags and config to inherit tracking, 2021-12-20) to use this discouraged combination for their --track flags. Fix this by removing PARSE_OPT_LITERAL_ARGHELP, and changing the arghelp to simply be "mode". Users may discover allowed values in the manual pages. [1]: https://lore.kernel.org/git/220111.86a6g3yqf9.gmgdl@evledraar.gmail.com/ Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-12Merge branch 'ps/lockfile-cleanup-fix'Libravatar Junio C Hamano2-7/+12
Some lockfile code called free() in signal-death code path, which has been corrected. * ps/lockfile-cleanup-fix: fetch: fix deadlock when cleaning up lockfiles in async signals
2022-01-10Merge branch 'en/stash-df-fix'Libravatar Junio C Hamano1-4/+5
"git stash apply" forgot to attempt restoring untracked files when it failed to restore changes to tracked ones. * en/stash-df-fix: stash: do not return before restoring untracked files
2022-01-10Merge branch 'ja/i18n-similar-messages'Libravatar Junio C Hamano29-97/+103
Similar message templates have been consolidated so that translators need to work on fewer number of messages. * ja/i18n-similar-messages: i18n: turn even more messages into "cannot be used together" ones i18n: ref-filter: factorize "%(foo) atom used without %(bar) atom" i18n: factorize "--foo outside a repository" i18n: refactor "unrecognized %(foo) argument" strings i18n: factorize "no directory given for --foo" i18n: factorize "--foo requires --bar" and the like i18n: tag.c factorize i18n strings i18n: standardize "cannot open" and "cannot read" i18n: turn "options are incompatible" into "cannot be used together" i18n: refactor "%s, %s and %s are mutually exclusive" i18n: refactor "foo and bar are mutually exclusive"
2022-01-10Merge branch 'js/branch-track-inherit'Libravatar Junio C Hamano2-4/+8
"git -c branch.autosetupmerge=inherit branch new old" makes "new" to have the same upstream as the "old" branch, instead of marking "old" itself as its upstream. * js/branch-track-inherit: config: require lowercase for branch.*.autosetupmerge branch: add flags and config to inherit tracking branch: accept multiple upstream branches for tracking
2022-01-10Merge branch 'ab/usage-die-message'Libravatar Junio C Hamano3-15/+20
Code clean-up to hide vreportf() from public API. * ab/usage-die-message: config API: use get_error_routine(), not vreportf() usage.c + gc: add and use a die_message_errno() gc: return from cmd_gc(), don't call exit() usage.c API users: use die_message() for error() + exit 128 usage.c API users: use die_message() for "fatal :" + exit 128 usage.c: add a die_message() routine
2022-01-10Merge branch 'ab/reflog-prep'Libravatar Junio C Hamano1-94/+129
Code refactoring in the reflog part of refs API. * ab/reflog-prep: reflog + refs-backend: move "verbose" out of the backend refs files-backend: assume cb->newlog if !EXPIRE_REFLOGS_DRY_RUN reflog: reduce scope of "struct rev_info" reflog expire: don't use lookup_commit_reference_gently() reflog expire: refactor & use "tip_commit" only for UE_NORMAL reflog expire: use "switch" over enum values reflog: change one->many worktree->refnames to use a string_list reflog expire: narrow scope of "cb" in cmd_reflog_expire() reflog delete: narrow scope of "cmd" passed to count_reflog_ent()
2022-01-10Merge branch 'ab/do-not-limit-stash-help-to-push'Libravatar Junio C Hamano1-0/+1
"git stash" by default triggers its "push" action, but its implementation also made "git stash -h" to show short help only for "git stash push", which has been corrected. * ab/do-not-limit-stash-help-to-push: stash: don't show "git stash push" usage on bad "git stash" usage
2022-01-10Merge branch 'ds/fetch-pull-with-sparse-index'Libravatar Junio C Hamano3-2/+14
"git fetch" and "git pull" are now declared sparse-index clean. Also "git ls-files" learns the "--sparse" option to help debugging. * ds/fetch-pull-with-sparse-index: test-read-cache: remove --table, --expand options t1091/t3705: remove 'test-tool read-cache --table' t1092: replace 'read-cache --table' with 'ls-files --sparse' ls-files: add --sparse option fetch/pull: use the sparse index
2022-01-10Merge branch 'ws/fast-export-with-revision-options'Libravatar Junio C Hamano1-36/+4
Use of certain "git rev-list" options with "git fast-export" created nonsense results (the worst two of which being "--reverse" and "--invert-grep --grep=<foo>"). The use of "--first-parent" is made to behave a bit more sensible than before. * ws/fast-export-with-revision-options: fast-export: fix surprising behavior with --first-parent
2022-01-10Merge branch 'ds/sparse-checkout-malformed-pattern-fix'Libravatar Junio C Hamano1-1/+4
Certain sparse-checkout patterns that are valid in non-cone mode led to segfault in cone mode, which has been corrected. * ds/sparse-checkout-malformed-pattern-fix: sparse-checkout: refuse to add to bad patterns sparse-checkout: fix OOM error with mixed patterns sparse-checkout: fix segfault on malformed patterns
2022-01-07fetch: fix deadlock when cleaning up lockfiles in async signalsLibravatar Patrick Steinhardt2-7/+12
When fetching packfiles, we write a bunch of lockfiles for the packfiles we're writing into the repository. In order to not leave behind any cruft in case we exit or receive a signal, we register both an exit handler as well as signal handlers for common signals like SIGINT. These handlers will then unlink the locks and free the data structure tracking them. We have observed a deadlock in this logic though: (gdb) bt #0 __lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 #1 0x00007f4932bea2cd in _int_free (av=0x7f4932f2eb20 <main_arena>, p=0x3e3e4200, have_lock=0) at malloc.c:3969 #2 0x00007f4932bee58c in __GI___libc_free (mem=<optimized out>) at malloc.c:2975 #3 0x0000000000662ab1 in string_list_clear () #4 0x000000000044f5bc in unlock_pack_on_signal () #5 <signal handler called> #6 _int_free (av=0x7f4932f2eb20 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:4024 #7 0x00007f4932bee58c in __GI___libc_free (mem=<optimized out>) at malloc.c:2975 #8 0x000000000065afd5 in strbuf_release () #9 0x000000000066ddb9 in delete_tempfile () #10 0x0000000000610d0b in files_transaction_cleanup.isra () #11 0x0000000000611718 in files_transaction_abort () #12 0x000000000060d2ef in ref_transaction_abort () #13 0x000000000060d441 in ref_transaction_prepare () #14 0x000000000060e0b5 in ref_transaction_commit () #15 0x00000000004511c2 in fetch_and_consume_refs () #16 0x000000000045279a in cmd_fetch () #17 0x0000000000407c48 in handle_builtin () #18 0x0000000000408df2 in cmd_main () #19 0x00000000004078b5 in main () The process was killed with a signal, which caused the signal handler to kick in and try free the data structures after we have unlinked the locks. It then deadlocks while calling free(3P). The root cause of this is that it is not allowed to call certain functions in async-signal handlers, as specified by signal-safety(7). Next to most I/O functions, this list of disallowed functions also includes memory-handling functions like malloc(3P) and free(3P) because they may not be reentrant. As a result, if we execute such functions in the signal handler, then they may operate on inconistent state and fail in unexpected ways. Fix this bug by not calling non-async-signal-safe functions when running in the signal handler. We're about to re-raise the signal anyway and will thus exit, so it's not much of a problem to keep the string list of lockfiles untouched. Note that it's fine though to call unlink(2), so we'll still clean up the lockfiles correctly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-05Merge branch 'ds/repack-fixlets'Libravatar Junio C Hamano1-3/+5
Two fixes around "git repack". * ds/repack-fixlets: repack: make '--quiet' disable progress repack: respect kept objects with '--write-midx -b'
2022-01-05Merge branch 'jc/merge-detached-head-name'Libravatar Junio C Hamano2-0/+8
The default merge message prepared by "git merge" records the name of the current branch; the name can be overridden with a new option to allow users to pretend a merge is made on a different branch. * jc/merge-detached-head-name: merge: allow to pretend a merge is made into a different branch
2022-01-05Merge branch 'xw/am-empty'Libravatar Junio C Hamano1-13/+76
"git am" learns "--empty=(stop|drop|keep)" option to tweak what is done to a piece of e-mail without a patch in it. * xw/am-empty: am: support --allow-empty to record specific empty patches am: support --empty=<option> to handle empty patches doc: git-format-patch: describe the option --always
2022-01-05Merge branch 'en/keep-cwd'Libravatar Junio C Hamano3-11/+40
Many git commands that deal with working tree files try to remove a directory that becomes empty (i.e. "git switch" from a branch that has the directory to another branch that does not would attempt remove all files in the directory and the directory itself). This drops users into an unfamiliar situation if the command was run in a subdirectory that becomes subject to removal due to the command. The commands have been taught to keep an empty directory if it is the directory they were started in to avoid surprising users. * en/keep-cwd: t2501: simplify the tests since we can now assume desired behavior dir: new flag to remove_dir_recurse() to spare the original_cwd dir: avoid incidentally removing the original_cwd in remove_path() stash: do not attempt to remove startup_info->original_cwd rebase: do not attempt to remove startup_info->original_cwd clean: do not attempt to remove startup_info->original_cwd symlinks: do not include startup_info->original_cwd in dir removal unpack-trees: add special cwd handling unpack-trees: refuse to remove startup_info->original_cwd setup: introduce startup_info->original_cwd t2501: add various tests for removing the current working directory
2022-01-05i18n: turn even more messages into "cannot be used together" onesLibravatar Jean-Noël Avila12-22/+23
Even if some of these messages are not subject to gettext i18n, this helps bring a single style of message for a given error type. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-05i18n: factorize "--foo requires --bar" and the likeLibravatar Jean-Noël Avila10-12/+12
They are all replaced by "the option '%s' requires '%s'", which is a new string but replaces 17 previous unique strings. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-05i18n: tag.c factorize i18n stringsLibravatar Jean-Noël Avila1-9/+14
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-05i18n: standardize "cannot open" and "cannot read"Libravatar Jean-Noël Avila1-2/+2
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-05i18n: turn "options are incompatible" into "cannot be used together"Libravatar Jean-Noël Avila20-39/+39
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-05i18n: refactor "%s, %s and %s are mutually exclusive"Libravatar Jean-Noël Avila3-3/+3
Use placeholders for constant tokens. The strings are turned into "cannot be used together" Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-05i18n: refactor "foo and bar are mutually exclusive"Libravatar Jean-Noël Avila7-10/+10
Use static strings for constant parts of the sentences. They are all turned into "cannot be used together". Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-04stash: do not return before restoring untracked filesLibravatar Elijah Newren1-4/+5
In commit bee8691f19 ("stash: restore untracked files AFTER restoring tracked files", 2021-09-10), we correctly identified that we should restore changes to tracked files before attempting to restore untracked files, and accordingly moved the code for restoring untracked files a few lines down in do_apply_stash(). Unfortunately, the intervening lines had some early return statements meaning that we suddenly stopped restoring untracked files in some cases. Even before the previous commit, there was another possible issue with the current code -- a post-stash-apply 'git status' that was intended to be run after restoring the stash was skipped when we hit a conflict (or other error condition), which seems slightly inconsistent. Fix both issues by saving the return status, and letting other functionality run before returning. Reported-by: AJ Henderson Test-case-by: Randall S. Becker <randall.becker@nexbridge.ca> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-03Merge branch 'en/sparse-checkout-set'Libravatar Junio C Hamano2-48/+158
The "init" and "set" subcommands in "git sparse-checkout" have been unified for a better user experience and performance. * en/sparse-checkout-set: sparse-checkout: remove stray trailing space clone: avoid using deprecated `sparse-checkout init` Documentation: clarify/correct a few sparsity related statements git-sparse-checkout.txt: update to document init/set/reapply changes sparse-checkout: enable reapply to take --[no-]{cone,sparse-index} sparse-checkout: enable `set` to initialize sparse-checkout mode sparse-checkout: split out code for tweaking settings config sparse-checkout: disallow --no-stdin as an argument to set sparse-checkout: add sanity-checks on initial sparsity state sparse-checkout: break apart functions for sparse_checkout_(set|add) sparse-checkout: pass use_stdin as a parameter instead of as a global
2022-01-03Merge branch 'ns/tmp-objdir'Libravatar Junio C Hamano2-5/+17
New interface into the tmp-objdir API to help in-core use of the quarantine feature. * ns/tmp-objdir: tmp-objdir: disable ref updates when replacing the primary odb tmp-objdir: new API for creating temporary writable databases
2022-01-03Merge branch 'jc/unleak-log'Libravatar Junio C Hamano1-0/+1
"git format-patch" uses a single rev_info instance and then exits. Mark the structure with UNLEAK() macro to squelch leak sanitizer. * jc/unleak-log: format-patch: mark rev_info with UNLEAK
2021-12-30sparse-checkout: refuse to add to bad patternsLibravatar Derrick Stolee1-0/+3
When in cone mode sparse-checkout, it is unclear how 'git sparse-checkout add <dir1> ...' should behave if the existing sparse-checkout file does not match the cone mode patterns. Change the behavior to fail with an error message about the existing patterns. Also, all cone mode patterns start with a '/' character, so add that restriction. This is necessary for our example test 'cone mode: warn on bad pattern', but also requires modifying the example sparse-checkout file we use to test the warnings related to recognizing cone mode patterns. This error checking would cause a failure further down the test script because of a test that adds non-cone mode patterns without cleaning them up. Perform that cleanup as part of the test now. Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-30sparse-checkout: fix OOM error with mixed patternsLibravatar Derrick Stolee1-1/+1
Add a test to t1091-sparse-checkout-builtin.sh that would result in an infinite loop and out-of-memory error before this change. The issue relies on having non-cone-mode patterns while trying to modify the patterns in cone-mode. The fix is simple, allowing us to break from the loop when the input path does not contain a slash, as the "dir" pattern we added does not. This is only a fix to the critical out-of-memory error. A better response to such a strange state will follow in a later change. Reported-by: Calbabreaker <calbabreaker@gmail.com> Helped-by: Taylor Blau <me@ttaylorr.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-23sparse-checkout: remove stray trailing spaceLibravatar Elijah Newren1-1/+1
Reported-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-22Merge branch 'ab/fetch-set-upstream-while-detached'Libravatar Junio C Hamano1-0/+10
"git fetch --set-upstream" did not check if there is a current branch, leading to a segfault when it is run on a detached HEAD, which has been corrected. * ab/fetch-set-upstream-while-detached: pull, fetch: fix segfault in --set-upstream option
2021-12-22reflog + refs-backend: move "verbose" out of the backendLibravatar Ævar Arnfjörð Bjarmason1-9/+47
Move the handling of the "verbose" flag entirely out of "refs/files-backend.c" and into "builtin/reflog.c". This allows the backend to stop knowing about the EXPIRE_REFLOGS_VERBOSE flag. The expire_reflog_ent() function shouldn't need to deal with the implementation detail of whether or not we're emitting verbose output, by doing this the --verbose output becomes backend-agnostic, so reftable will get the same output. I think the output is rather bad currently, and should e.g. be implemented with some better future mode of progress.[ch], but that's a topic for another improvement. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-22reflog: reduce scope of "struct rev_info"Libravatar Ævar Arnfjörð Bjarmason1-6/+7
Change the "cmd.stalefix" handling added in 1389d9ddaa6 (reflog expire --fix-stale, 2007-01-06) to use a locally scoped "struct rev_info". This code relies on mark_reachable_objects() twiddling flags in the walked objects. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-22reflog expire: don't use lookup_commit_reference_gently()Libravatar Ævar Arnfjörð Bjarmason1-2/+1
In the initial implementation of "git reflog" in 4264dc15e19 (git reflog expire, 2006-12-19) we had this lookup_commit_reference_gently(). I don't think we've ever found tags that we need to recursively dereference in reflogs, so this should at least be changed to a "lookup commit" as I'm doing here, although I can't think of a way where it mattered in practice. I also think we'd probably like to just die here if we have a NULL object, but as this code needs to handle potentially broken repositories let's just show an "error" but continue, the non-quiet lookup_commit() will do for us. None of our tests cover the case where "commit" is NULL after this lookup. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-22reflog expire: refactor & use "tip_commit" only for UE_NORMALLibravatar Ævar Arnfjörð Bjarmason1-7/+7
Add an intermediate variable for "tip_commit" in reflog_expiry_prepare(), and only add it to the struct if we're handling the UE_NORMAL case. The code behaves the same way as before, but this makes the control flow clearer, and the shorter name allows us to fold a 4-line i/else into a one-line ternary instead. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-22reflog expire: use "switch" over enum valuesLibravatar Ævar Arnfjörð Bjarmason1-24/+33
Change code added in 03cb91b18cc (reflog --expire-unreachable: special case entries in "HEAD" reflog, 2010-04-09) to use a "switch" statement with an exhaustive list of "case" statements instead of doing numeric comparisons against the enum labels. Now we won't assume that "x != UE_ALWAYS" means "(x == UE_HEAD || x || UE_NORMAL)". That assumption is true now, but we'd introduce subtle bugs here if that were to change, now the compiler will notice and error out on such errors. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-22reflog: change one->many worktree->refnames to use a string_listLibravatar Ævar Arnfjörð Bjarmason1-29/+18
Change the FLEX_ARRAY pattern added in bda3a31cc79 (reflog-expire: Avoid creating new files in a directory inside readdir(3) loop, 2008-01-25) the string-list API instead. This does not change any behavior, allows us to delete much of this code as it's replaced by things we get from the string-list API for free, as a result we need just one struct to keep track of this data, instead of two. The "DUP" -> "string_list_append_nodup(..., strbuf_detach(...))" pattern here is the same as that used in a recent memory leak fix in b202e51b154 (grep: fix a "path_list" memory leak, 2021-10-22). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-22reflog expire: narrow scope of "cb" in cmd_reflog_expire()Libravatar Ævar Arnfjörð Bjarmason1-16/+15
As with the preceding change for "reflog delete", change the "cb_data" we pass to callbacks to be &cb.cmd itself, instead of passing &cb and having the callback lookup cb->cmd. This makes it clear that the "cb" itself is the same memzero'd structure on each iteration of the for-loops that use &cb, except for the "cmd" member. The "struct expire_reflog_policy_cb" we pass to reflog_expire() will have the members that aren't "cmd" modified by the callbacks, but before we invoke them everything except "cmd" is zero'd out. This included the "tip_commit", "mark_list" and "tips". It might have looked as though we were re-using those between iterations, but the first thing we did in reflog_expiry_prepare() was to either NULL them, or clobber them with another value. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>