summaryrefslogtreecommitdiffstats
path: root/t/t9137-git-svn-dcommit-clobber-series.sh (unfollow)
Commit message (Collapse)AuthorFilesLines
2020-12-08t7900: fix typo: "test_execpt_success"Josh Steadmon1-1/+1
Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-07completion: bash: fix gitk alias regressionFelipe Contreras1-1/+1
Long time ago when the _git_complete helper was introduced, _gitk was replaced with __gitk_main, and a placeholder for backwards compatibility pointing to __git_wrap_main_gitk was left in place. When "__git_complete gitk __gitk_main" was called, that created the __git_wrap__gitk_main helper, which is just basically "__git_func_wrap __gitk_main" plus `complete` options. Unfortunately the commit b0a4b2d257 (completion: add support for backwards compatibility, 2012-05-19) missed a previous instance of a call to _gitk in _git_gitk So, basically we had __git_wrap__git_main -> __git_func_wrap __git_main -> __git_complete_command gitk -> _git_gitk -> _gitk -> __git_wrap__gitk_main -> __git_func_wrap __gitk_main -> __gitk_main. There was never any need to call __git_func_wrap twice. Since _git_gitk is always called inside the wrapper, it can call __gitk_main directly. And then, in commit 441ecdab37 (completion: bash: remove old compat wrappers, 2020-10-27) _gitk was removed, which triggers the following error: _git_gitk:9: command not found: _gitk Let's call the correct function: __gitk_main. Cc: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-04ci(vs-build): stop passing the iconv library location explicitlyDennis Ameling3-3/+2
Something changed in `vcpkg` (which we use in our Visual C++ build to provide the dependencies such as libcurl) and our `vs-build` job started failing in CI. The reason is that we had a work-around in place to help CMake find iconv, and this work-around is neither needed nor does it work anymore. For the full discussion with the vcpkg project, see this comment: https://github.com/microsoft/vcpkg/issues/14780#issuecomment-735368280 Signed-off-by: Dennis Ameling <dennis@dennisameling.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-03style: indent multiline "if" conditions to alignJeff King2-2/+2
Commit 6dc905d974 (config: split repo scope to local and worktree, 2020-02-10) made some "if" statements multiline, but didn't indent the second lines in our usual way. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-03upload-pack: propagate return value from object filter config callbackJeff King2-1/+10
If we encounter an error in parse_filter_object_config(), we'll complain to stderr but won't actually propagate the return value up the stack. This is unlike most of our config callbacks, which return the error to git_config() so it can die (this includes the call just below us to parse_hide_refs_config(), which can also produce errors). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-03Tenth batchJunio C Hamano1-5/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-03doc: make HTML manual reproducibleArnout Engelen1-1/+4
Versions of docbook-xsl newer than 1.79.1 allows xsltproc to assign IDs to nodes in the generated HTML consistently, to make the output resulting from the same source stable and reproducible. Pass the generate.consistent.ids parameter from the command line to ask for this feature. Older versions of the tool simply ignores the parameter and produces their output the same way as before this change, so there is no need to check for toolchain version. Signed-off-by: Arnout Engelen <arnout@bzzt.net> Helped-by: brian m. carlson <sandals@crustytoothpaste.net> Helped-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-03Revert "submodules: fix of regression on fetching of non-init subsub-repo"Junio C Hamano2-67/+10
This reverts commit 1b7ac4e6d4d490b224f5206af7418ed74e490608; in <CAN0XMOLiS_8JZKF_wW70BvRRxkDHyUoa=Z3ODtB_Bd6f5Y=7JQ@mail.gmail.com>, Ralf Thielow reports that "git fetch" with submodule.recurse set can result in a bogus and infinitely recursive fetching of the same submodule.
2020-12-02glossary: improve "branch" definitionSergey Organov1-1/+1
The old phrasing is at least questionable, if not wrong, as there are a lot of branches out there that didn't see active development for years, yet they are still branches, ready to become active again any time. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-02Makefile: mark git-maintenance as a builtinJeff King1-0/+1
We normally get the list of builtin commands by expanding BUILTIN_OBJS. But for commands which are embedded inside another's source file (e.g., cmd_show() in builtin/log.c), the Makefile needs to be told explicitly about them. Since cmd_maintenance() is inside buitin/gc.c, it should be listed explicitly in the BUILT_INS list in the Makefile. Not doing so isn't _too_ tragic, as it simply means we will not make a git-maintenance symlink in libexec/git-core. Since we encourage people to use the "git foo" form, even in scripts which have put libexec into their PATH, nobody seems to have noticed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-02apply: don't use core.sharedRepository to create working tree filesMatheus Tavares5-6/+47
core.sharedRepository defines which permissions Git should set when creating files in $GIT_DIR, so that the repository may be shared with other users. But (in its current form) the setting shouldn't affect how files are created in the working tree. This is not respected by apply and am (which uses apply), when creating leading directories: $ cat d.patch diff --git a/d/f b/d/f new file mode 100644 index 0000000..e69de29 Apply without the setting: $ umask 0077 $ git apply d.patch $ ls -ld d drwx------ Apply with the setting: $ umask 0077 $ git -c core.sharedRepository=0770 apply d.patch $ ls -ld d drwxrws--- Only the leading directories are affected. That's because they are created with safe_create_leading_directories(), which calls adjust_shared_perm() to set the directories' permissions based on core.sharedRepository. To fix that, let's introduce a variant of this function that ignores the setting, and use it in apply. Also add a regression test and a note in the function documentation about the use of each variant according to the destination (working tree or git dir). Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-02banned.h: mark ctime_r() and asctime_r() as bannedJeff King1-0/+4
The ctime_r() and asctime_r() functions are reentrant, but have no check that the buffer we pass in is long enough (the manpage says it "should have room for at least 26 bytes"). Since this is such an easy-to-get-wrong interface, and since we have the much safer strftime() as well as its more convenient strbuf_addftime() wrapper, let's ban both of those. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-02gitignore: remove entry for git serveRené Scharfe1-1/+0
b7ce24d095 (Turn `git serve` into a test helper, 2019-04-18) demoted git serve from a builtin command to a test helper. As a result the git-serve binary is no longer built and thus doesn't have to be ignored anymore. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-02gitignore: drop duplicate entry for git-sh-i18nJeff King1-1/+0
This was accidentally added by e00cf070a4 (git-sh-i18n.sh: add no-op gettext() and eval_gettext() wrappers, 2011-05-14), even though an earlier commit in the same series had already done so. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-02t7900: speed up expensive testJeff King1-2/+4
A test marked with EXPENSIVE creates two 2.5GB files and adds them to the repository. This takes 194s to run on my machine, versus 2s when the EXPENSIVE prereq isn't set. We can trim this down a bit by doing two things: - use "git commit --quiet" to avoid spending time generating a diff summary (this actually only helps for the second commit, but I've added it here to both for consistency). This shaves off 8s. - set core.compression to 0. We know these files are full of random bytes, and so won't compress (that's the point of the test!). Spending cycles on zlib is pointless. This shaves off 122s. After this, my total time to run the script is 64s. That won't help normal runs without GIT_TEST_LONG set, of course, but it's easy enough to do. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01banned.h: mark non-reentrant gmtime, etc as bannedJeff King1-0/+9
The traditional gmtime(), localtime(), ctime(), and asctime() functions return pointers to shared storage. This means they're not thread-safe, and they also run the risk of somebody holding onto the result across multiple calls (where each call invalidates the previous result). All callers should be using their reentrant counterparts. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01config.txt: fix a typo (backslash != backquote)Štěpán Němec1-1/+1
Signed-off-by: Štěpán Němec <stepnem@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01builtin/bugreport.c: use thread-safe localtime_r()Taylor Blau1-1/+2
To generate its filename, the 'git bugreport' builtin asks the system for the current time with 'localtime()'. Since this uses a shared buffer, it is not thread-safe. Even though 'git bugreport' is not multi-threaded, using localtime() can trigger some static analysis tools to complain, and a quick $ git grep -oh 'localtime\(_.\)\?' -- **/*.c | sort | uniq -c shows that the only usage of the thread-unsafe 'localtime' is in a piece of documentation. So, convert this instance to use the thread-safe version for consistency, and to appease some analysis tools. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01upload-pack: kill pack-objects helper on signal or exitJeff King1-0/+1
We spawn an external pack-objects process to actually send objects to the remote side. If we are killed by a signal during this process, then pack-objects may continue to run. As soon as it starts producing output for the pack, it will see a failure writing to upload-pack and exit itself. But before then, it may do significant work traversing the object graph, compressing deltas, etc, which will all be pointless. So let's make sure to kill as soon as we know that the caller will not read the result. There's no test here, since it's inherently racy, but here's an easy reproduction is on a large-ish repo like linux.git: - make sure you don't have pack bitmaps (since they make the enumerating phase go quickly). For linux.git it takes ~30s or so to walk the whole graph on my machine. - run "git clone --no-local -q . dst"; the "-q" is important because if pack-objects is writing progress to upload-pack (to get multiplexed over the sideband to the client), then it will notice pretty quickly the failure to write to stderr - kill the client-side clone process in another terminal (don't use ^C, as that will send SIGINT to all of the processes) - run "ps au | grep git" or similar to observe upload-pack dying within 5 seconds (it will send a keepalive that will notice the client has gone away) - but you'll still see pack-objects consuming 100% CPU (and 1GB+ of RAM) during the traversal and delta compression phases. It will exit as soon as it starts to write the pack (when it will notice that upload-pack went away). With this patch, pack-objects exits as soon as upload-pack does. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01imap-send: parse default git configNicolas Morey-Chaisemartin1-22/+30
git imap-send does not parse the default git config settings and thus ignore core.askpass value. Rewrite config parsing to support core settings. Reported-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Nicolas Morey-Chaisemartin <nmoreychaisemartin@suse.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01completion: zsh: fix file completion regressionFelipe Contreras1-0/+1
Turns out we always need to set the ignored prefix (compset) to have similar behavior as in default Bash. The issue can be seen with: git show master:<tab> Commit 94b2901cfe wrongly removed it. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01tests: lib-functions: trivial style cleanupsFelipe Contreras1-4/+4
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01test: completion: fix typosFelipe Contreras1-2/+2
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01.gitignore: remove dangling fileFelipe Contreras1-1/+0
The library was removed 7 years ago on commit ae34ac126f. But not from the .gitignore file. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01refspec: trivial cleanupFelipe Contreras1-9/+10
We can remove one level of indentation and make the code clearer. No functional changes. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-30Ninth batchJunio C Hamano1-0/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-30fetch-pack: disregard invalid pack lockfilesRené Scharfe1-2/+3
9da69a6539 (fetch-pack: support more than one pack lockfile, 2020-06-10) started to use a string_list for pack lockfile names instead of a single string pointer. It removed a NULL check from transport_unlock_pack() as well, which is the function that eventually deletes these lockfiles and releases their name strings. index_pack_lockfile() can return NULL if it doesn't like the contents it reads from the file descriptor passed to it. unlink(2) is declared to not accept NULL pointers (at least with glibc). Undefined Behavior Sanitizer together with Address Sanitizer detects a case where a NULL lockfile name is passed to unlink(2) by transport_unlock_pack() in t1060 (make SANITIZE=address,undefined; cd t; ./t1060-object-corruption.sh). Reinstate the NULL check to avoid undefined behavior, but put it right at the source, so that the number of items in the string_list reflects the number of valid lockfiles. Signed-off-by: René Scharfe <l.s.r@web.de> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-30refspec: make @ a synonym of HEADFelipe Contreras3-52/+62
Since commit 9ba89f484e git learned how to push to a remote branch using the source @, for example: git push origin @:master However, if the right-hand side is missing, the push fails: git push origin @ It is obvious what is the desired behavior, and allowing the push makes things more consistent. Additionally, @:master now has the same semantics as HEAD:master. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-30tests: push: trivial cleanupFelipe Contreras1-2/+1
No need to do two checkouts. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-30tests: push: improve cleanup of HEAD testsFelipe Contreras1-1/+3
So that we are not left in an inconsistent state between them. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-30MyFirstObjectWalk: drop `init_walken_defaults()`Martin Ågren1-24/+0
In a recent commit, we stopped calling `init_grep_defaults()` from this function. Thus, by the end of the tutorial, we still haven't added any contents to this function. Let's remove it for simplicity. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-30grep: copy struct in one fell swoopMartin Ågren1-23/+10
We have a `struct grep_opt` with our defaults which we then copy into the caller's struct. Rather than zeroing the target struct and copying each element one by one, just copy everything at once. This leaves the code simpler and more maintainable. We don't have any ownership issues with what we're copying now and can just greedily copy the whole thing. If and when we do need to handle such elements (`char *`?), we must and can handle it appropriately. Make sure to leave a comment to our future selves. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-30perf/fsmonitor: use test_must_be_empty helperNipunn Koorapati1-2/+1
Simplify test and make error messages more clear here. Per feedback from Junio in 33226af42b (t/perf/fsmonitor: improve error message if typoing hook name, 2020-10-26) Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-30maintenance: fix SEGFAULT when no repositoryRafael Silva3-8/+9
The "git maintenance run" and "git maintenance start/stop" commands holds a file-based lock at the .git/maintenance.lock and .git/schedule.lock respectively. These locks are used to ensure only one maintenance process is executed at the time as both operations involves writing data into the git repository. The path to the lock file is built using "the_repository->objects->odb->path" that results in SEGFAULT when we have no repository available as "the_repository->objects->odb" is set to NULL. Let's teach maintenance command to use RUN_SETUP option that will provide the validation and fail when running outside of a repository. Hence fixing the SEGFAULT for all three operations and making the behaviour consistent across all subcommands. Setting the RUN_SETUP also provides the same protection for all subcommands given that the "register" and "unregister" also requires to be executed inside a repository. Furthermore let's remove the local validation implemented by the "register" and "unregister" as this will not be required anymore with the new option. Signed-off-by: Rafael Silva <rafaeloliveira.cs@gmail.com> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-26Eighth batchJunio C Hamano1-0/+32
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-26maintenance: use 'git config --fixed-value'Derrick Stolee2-2/+15
When a repository's leading directories contain regex metacharacters, the config calls for 'git maintenance register' and 'git maintenance unregister' are not careful enough. Use the new --fixed-value option to direct the config machinery to use exact string matches. This is a more robust option than escaping these arguments in a piecemeal fashion. For the test, require that we are not running on Windows since the '+' and '*' characters are not allowed on that filesystem. Reported-by: Emily Shaffer <emilyshaffer@google.com> Reported-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-26config doc: value-pattern is not necessarily a regexpJunio C Hamano1-4/+7
The introductory part of the "git config --help" mentions the optional value-pattern argument, but give no hint that it can be something other than a regular expression (worse, it just says "POSIX regexp", which usually means BRE but the regexp the command takes is ERE). Also, it needs to be documented that the '!' prefix to negate the match, which is only mentioned in this part of the document, works only with regexp and not with the --fixed-value. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25config: implement --fixed-value with --get*Derrick Stolee2-5/+32
The config builtin does its own regex matching of values for the --get, --get-all, and --get-regexp modes. Plumb the existing 'flags' parameter to the get_value() method so we can initialize the value-pattern argument as a fixed string instead of a regex pattern. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25config: plumb --fixed-value into config APIDerrick Stolee4-5/+73
The git_config_set_multivar_in_file_gently() and related methods now take a 'flags' bitfield, so add a new bit representing the --fixed-value option from 'git config'. This alters the purpose of the value_pattern parameter to be an exact string match. This requires some initialization changes in git_config_set_multivar_in_file_gently() and a new strcmp() call in the matches() method. The new CONFIG_FLAGS_FIXED_VALUE flag is initialized in builtin/config.c based on the --fixed-value option, and that needs to be updated in several callers. This patch only affects some of the modes of 'git config', and the rest will be completed in the next change. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25config: add --fixed-value option, un-implementedDerrick Stolee3-7/+73
The 'git config' builtin takes a 'value-pattern' parameter for several actions. This can cause confusion when expecting exact value matches instead of regex matches, especially when the input string contains metacharacters. While callers can escape the patterns themselves, it would be more friendly to allow an argument to disable the pattern matching in favor of an exact string match. Add a new '--fixed-value' option that does not currently change the behavior. The implementation will be filled in by later changes for each appropriate action. For now, check and test that --fixed-value will abort the command when included with an incompatible action or without a 'value-pattern' argument. The name '--fixed-value' was chosen over something simpler like '--fixed' because some commands allow regular expressions on the key in addition to the value. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25t1300: add test for --replace-all with value-patternDerrick Stolee1-0/+14
The --replace-all option was added in 4ddba79d (git-config-set: add more options) but was not tested along with the 'value-pattern' parameter. Since we will be updating this option to optionally treat 'value-pattern' as a fixed string, let's add a test here that documents the current behavior. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25t1300: test "set all" mode with value-patternDerrick Stolee1-0/+39
Without additional modifiers, 'git config <key> <value>' attempts to set a single value in the .git/config file. When the value-pattern parameter is supplied, this command behaves in a non-trivial manner. Consider 'git config <key> <value> <value-pattern>'. The expected behavior is as follows: 1. If there are multiple existing values that match 'value-pattern', then the command fails. Users should use --replace-all instead. 2. If there is no existing values match 'value-pattern', then the 'key=value' pair is appended, making this 'key' a multi-valued config setting. 3. If there is one existing value that matches 'value-pattern', then the new config has one entry where 'key=value'. Add a test that demonstrates these options. Break from the existing pattern in t1300-config.sh to use 'git config --file=<file>' instead of modifying .git/config directly to prevent possibly incompatible repo states. Also use 'git config --file=<file> --list' for config state comparison instead of the config file format. This makes the tests more readable. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25config: replace 'value_regex' with 'value_pattern'Derrick Stolee4-44/+44
The 'value_regex' argument in the 'git config' builtin is poorly named, especially related to an upcoming change that allows exact string matches instead of ERE pattern matches. Perform a mostly mechanical change of every instance of 'value_regex' to 'value_pattern' in the codebase. This is only critical for documentation and error messages, but it is best to be consistent inside the codebase, too. For documentation, use 'value-pattern' which is better punctuation. This affects Documentation/git-config.txt and the usage in builtin/config.c, which was already mixed between 'value_regex' and 'value-regex'. I gave some thought to leaving the value_regex variables inside config.c that are regex_t pointers. However, it is probably best to keep the name consistent with the rest of the variables. This does not update the translations inside the po/ directory, as that creates conflicts with ongoing work. The input strings should automatically update through automation, and a few of the output strings currently use "[value_regex]" directly. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25config: convert multi_replace to flagsDerrick Stolee5-26/+45
We will extend the flexibility of the config API. Before doing so, let's take an existing 'int multi_replace' parameter and replace it with a new 'unsigned flags' parameter that can take multiple options as a bit field. Update all callers that specified multi_replace to now specify the CONFIG_FLAGS_MULTI_REPLACE flag. To add more clarity, extend the documentation of git_config_set_multivar_in_file() including a clear labeling of its arguments. Other config API methods in config.h require only a change of the final parameter from 'int' to 'unsigned'. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25midx.c: protect against disappearing packsTaylor Blau2-2/+8
When a packed object is stored in a multi-pack index, but that pack has racily gone away, the MIDX code simply calls die(), when it could be returning an error to the caller, which would in turn lead to re-scanning the pack directory. A pack can racily disappear, for example, due to a simultaneous 'git repack -ad', You can also reproduce this with two terminals, where one is running: git init while true; do git commit -q --allow-empty -m foo git repack -ad git multi-pack-index write done (in effect, constantly writing new MIDXs), and the other is running: obj=$(git rev-parse HEAD) while true; do echo $obj | git cat-file --batch-check='%(objectsize:disk)' || break done That will sometimes hit the error preparing packfile from multi-pack-index message, which this patch fixes. Right now, that path to discovering a missing pack looks something like 'find_pack_entry()' calling 'fill_midx_entry()' and eventually making its way to call 'nth_midxed_pack_entry()'. 'nth_midxed_pack_entry()' already checks 'is_pack_valid()' and propagates an error if the pack is invalid. So, this works if the pack has gone away between calling 'prepare_midx_pack()' and before calling 'is_pack_valid()', but not if it disappears before then. Catch the case where the pack has already disappeared before 'prepare_midx_pack()' by returning an error in that case, too. Co-authored-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25packfile.c: protect against disappearing indexesTaylor Blau2-19/+24
In 17c35c8969 (packfile: skip loading index if in multi-pack-index, 2018-07-12) we stopped loading the .idx file for packs that are contained within a multi-pack index. This saves us the effort of loading an .idx and doing some lightweight validity checks by way of 'packfile.c:load_idx()', but introduces a race between processes that need to load the index (e.g., to generate a reverse index) and processes that can delete the index. For example, running the following in your shell: $ git init repo && cd repo $ git commit --allow-empty -m 'base' $ git repack -ad && git multi-pack-index write followed by: $ rm -f .git/objects/pack/pack-*.idx $ git rev-parse HEAD | git cat-file --batch-check='%(objectsize:disk)' will result in a segfault prior to this patch. What's happening here is that we notice that the pack is in the multi-pack index, and so don't check that it still has a .idx. When we then try and load that index to generate a reverse index, we don't have it, so the call to 'find_pack_revindex()' in 'packfile.c:packed_object_info()' returns NULL, and then dereferencing it causes a segfault. Of course, we don't ever expect someone to remove the index file by hand, or to be in a state where we never wrote it to begin with (yet find that pack in the multi-pack-index). But, this can happen in a timing race with 'git repack -ad', which removes all existing packs after writing a new pack containing all of their objects. Avoid this by reverting the hunk of 17c35c8969 which stops loading the index when the pack is contained in a MIDX. This makes the latter half of 17c35c8969 useless, since we'll always have a non-NULL 'p->index_data', in which case that if statement isn't guarding anything. These two together effectively revert 17c35c8969, and avoid the race explained above. Co-authored-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25help.c: help.autocorrect=never means "do not compute suggestions"Drew DeVault3-18/+52
While help.autocorrect can be set to 0 to decline auto-execution of possibly mistyped commands, it still spends cycles to compute the suggestions, and it wastes screen real estate. Update help.autocorrect to accept the string "never" to just exit with error upon mistyped commands to help users who prefer to never see suggested corrections at all. While at it, introduce "immediate" as a more readable way to immediately execute the auto-corrected command, which can be done with negative value. Signed-off-by: Drew DeVault <sir@cmpwn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25crendential-store: use timeout when locking fileSimão Afonso2-2/+12
When holding the lock for rewriting the credential file, use a timeout to avoid race conditions when the credentials file needs to be updated in parallel. An example would be doing `fetch --all` on a repository with several remotes that need credentials, using parallel fetching. The timeout can be configured using "credentialStore.lockTimeoutMS", defaulting to 1 second. Signed-off-by: Simão Afonso <simao.afonso@powertools-tech.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25move sleep_millisec to git-compat-util.hHan-Wen Nienhuys2-1/+2
The sleep function is defined in wrapper.c, so it makes more sense to be a in system compatibility header. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25usage: add trace2 entry upon warning()Jonathan Tan2-1/+7
Emit a trace2 error event whenever warning() is called, just like when die(), error(), or usage() is called. This helps debugging issues that would trigger warnings but not errors. In particular, this might have helped debugging an issue I encountered with commit graphs at $DAYJOB [1]. There is a tradeoff between including potentially relevant messages and cluttering up the trace output produced. I think that warning() messages should be included in traces, because by its nature, Git is used over multiple invocations of the Git tool, and a failure (currently traced) in a Git invocation might be caused by an unexpected interaction in a previous Git invocation that only has a warning (currently untraced) as a symptom - as is the case in [1]. [1] https://lore.kernel.org/git/20200629220744.1054093-1-jonathantanmy@google.com/ Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-21 06:00:58 +0100