summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-10-04Merge branch 'jc/fmt-merge-msg-suppress-destination'Junio C Hamano
Docfix. * jc/fmt-merge-msg-suppress-destination: config/fmt-merge-msg.txt: drop space in quote
2020-10-04Merge branch 'tb/upload-pack-filters'Junio C Hamano
Hotfix. * tb/upload-pack-filters: config/uploadpack.txt: fix typo in `--filter=tree:<n>`
2020-10-04Merge branch 'jc/sequencer-stopped-sha-simplify'Junio C Hamano
Code simplification. * jc/sequencer-stopped-sha-simplify: sequencer: stop abbreviating stopped-sha file
2020-10-04Merge branch 'au/complete-restore-s'Junio C Hamano
The command line completion (in contrib/) learned that "git restore -s <TAB>" is often followed by a refname. * au/complete-restore-s: completion: complete refs after 'git restore -s' completion: use "prev" variable instead of introducing "prevword"
2020-10-04Merge branch 'al/ref-filter-merged-and-no-merged'Junio C Hamano
Hotfix. * al/ref-filter-merged-and-no-merged: ref-filter: plug memory leak in reach_filter()
2020-10-04Merge branch 'eg/mailinfo-doc-scissors'Junio C Hamano
The explanation of the "scissors line" has been clarified. * eg/mailinfo-doc-scissors: Doc: show example scissors line
2020-10-04Merge branch 'mr/bisect-in-c-2'Junio C Hamano
Rewrite of the "git bisect" script in C continues. * mr/bisect-in-c-2: bisect--helper: reimplement `bisect_next` and `bisect_auto_next` shell functions in C bisect: call 'clear_commit_marks_all()' in 'bisect_next_all()' bisect--helper: reimplement `bisect_autostart` shell function in C bisect--helper: introduce new `write_in_file()` function bisect--helper: use '-res' in 'cmd_bisect__helper' return bisect--helper: BUG() in cmd_*() on invalid subcommand
2020-10-04Merge branch 'cc/bisect-start-fix'Junio C Hamano
"git bisect start X Y", when X and Y are not valid committish object names, should take X and Y as pathspec, but didn't. * cc/bisect-start-fix: bisect: don't use invalid oid as rev when starting
2020-10-04Merge branch 'jc/blame-ignore-fix'Junio C Hamano
"git blame --ignore-rev/--ignore-revs-file" failed to validate their input are valid revision, and failed to take into account that the user may want to give an annotated tag instead of a commit, which has been corrected. * jc/blame-ignore-fix: blame: validate and peel the object names on the ignore list t8013: minimum preparatory clean-up
2020-10-04Merge branch 'jk/drop-unaligned-loads'Junio C Hamano
Compilation fix around type punning. * jk/drop-unaligned-loads: Revert "fast-export: use local array to store anonymized oid" bswap.h: drop unaligned loads
2020-10-04Merge branch 'js/no-builtins-on-disk-option'Junio C Hamano
The installation procedure learned to optionally omit "git-foo" executable files for each 'foo' built-in subcommand, which are only required by old timers that still rely on the age old promise that prepending "git --exec-path" output to PATH early in their script will keep the "git-foo" calls they wrote working. The old attempt to remove these executables from the disk failed in the 1.6 era; it may be worth attempting again, but I think it is worth to keep this topic separate from such a policy change to help it graduate early. * js/no-builtins-on-disk-option: ci: stop linking built-ins to the dashed versions Optionally skip linking/copying the built-ins msvc: copy the correct `.pdb` files in the Makefile target `install`
2020-10-04Merge branch 'ab/mediawiki-fixes'Junio C Hamano
Modernization and fixes to MediaWiki remote backend. * ab/mediawiki-fixes: remote-mediawiki: use "sh" to eliminate unquoted commands remote-mediawiki: annotate unquoted uses of run_git() remote-mediawiki: convert to quoted run_git() invocation remote-mediawiki: provide a list form of run_git() remote-mediawiki tests: annotate failing tests remote-mediawiki: fix duplicate revisions being imported remote-mediawiki tests: use CLI installer remote-mediawiki tests: use inline PerlIO for readability remote-mediawiki tests: replace deprecated Perl construct remote-mediawiki tests: use a more idiomatic dispatch table remote-mediawiki tests: use "$dir/" instead of "$dir." remote-mediawiki tests: change `[]` to `test` remote-mediawiki tests: use test_cmp in tests remote-mediawiki tests: use a 10 character password remote-mediawiki tests: use the login/password variables remote-mediawiki doc: don't hardcode Debian PHP versions remote-mediawiki doc: link to MediaWiki's current version remote-mediawiki doc: correct link to GitHub project
2020-10-03credential: treat CR/LF as line endings in the credential protocolNikita Leonov
This fix makes using Git credentials more friendly to Windows users: it allows a credential helper to communicate using CR/LF line endings ("DOS line endings" commonly found on Windows) instead of LF-only line endings ("Unix line endings"). Note that this changes the behavior a bit: if a credential helper produces, say, a password with a trailing Carriage Return character, that will now be culled even when the rest of the lines end only in Line Feed characters, indicating that the Carriage Return was not meant to be part of the line ending. In practice, it seems _very_ unlikely that something like this happens. Passwords usually need to consist of non-control characters, URLs need to have special characters URL-encoded, and user names, well, are names. However, it _does_ help on Windows, where CR/LF line endings are common: as unrecognized commands are simply ignored by the credential machinery, even a command like `quit\r` (which is clearly intended to abort) would simply be ignored (silently) by Git. So let's change the credential machinery to accept both CR/LF and LF line endings. While we do this for the credential helper protocol, we do _not_ adjust `git credential-cache--daemon` (which won't work on Windows, anyway, because it requires Unix sockets) nor `git credential-store` (which writes the file `~/.git-credentials` which we consider an implementation detail that should be opaque to the user, read: we do expect users _not_ to edit this file manually). Signed-off-by: Nikita Leonov <nykyta.leonov@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-03Merge remote-tracking branch 'paulus/master' into pm/gitk-updateJunio C Hamano
* paulus/master: gitk: Resize panes correctly when reducing window size gitk: replace tabs with spaces gitk: fix the context menu not appearing in the presence of submodule diffs gitk: Un-hide selection in areas with non-default background color gitk: add diff lines background colors gitk: be prepared to be run in a bare repository gitk: Preserve window dimensions on exit when not using ttk themes gitk: don't highlight files after submodules as submodules gitk: fix branch name encoding error gitk: rename "commit summary" to "commit reference"
2020-10-03gitk: Resize panes correctly when reducing window sizePaul Mackerras
The resizeclistpanes and resizecdetpanes procedures attempt to keep the horizontal proportions of the panes of the gitk window approximately constant when the gitk window is resized. However, if the size is reduced enough that an existing sash position would go outside the window, Tk moves the sash to the left to keep it inside the window (without moving other sash positions to keep the proportions). This happens before these resize procedures get control, and so they work with incorrect proportions. To fix this, we record the sash positions we set previously and use those previously-set sash positions rather than the current sash positions when computing the proportions. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2020-10-03gitk: replace tabs with spacesDenton Liu
The source code is a mix of tabs and spaces. The indentation style currently is four spaces per indent level but uses tabs every other level (at eight spaces). Fix this inconsistent spacing and tabbing by just using a space-indent for everything. This was done mechanically by running: $ expand -i gitk >gitk.new $ mv gitk.new gitk This patch should be empty with `--ignore-all-space`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2020-10-02commit-reach: fix in_merge_bases_many bugDerrick Stolee
Way back in f9b8908b (commit.c: use generation numbers for in_merge_bases(), 2018-05-01), a heuristic was used to short-circuit the in_merge_bases() walk. This works just fine as long as the caller is checking only two commits, but when there are multiple, there is a possibility that this heuristic is _very wrong_. Some code moves since then has changed this method to repo_in_merge_bases_many() inside commit-reach.c. The heuristic computes the minimum generation number of the "reference" list, then compares this number to the generation number of the "commit". In a recent topic, a test was added that used in_merge_bases_many() to test if a commit was reachable from a number of commits pulled from a reflog. However, this highlighted the problem: if any of the reference commits have a smaller generation number than the given commit, then the walk is skipped _even if there exist some with higher generation number_. This heuristic is wrong! It must check the MAXIMUM generation number of the reference commits, not the MINIMUM. This highlights a testing gap. t6600-test-reach.sh covers many methods in commit-reach.c, including in_merge_bases() and get_merge_bases_many(), but since these methods either restrict to two input commits or actually look for the full list of merge bases, they don't check this heuristic! Add a possible input to "test-tool reach" that tests in_merge_bases_many() and add tests to t6600-test-reach.sh that cover this heuristic. This includes cases for the reference commits having generation above and below the generation of the input commit, but also having maximum generation below the generation of the input commit. The fix itself is to swap min_generation with a max_generation in repo_in_merge_bases_many(). Reported-by: Srinidhi Kaushik <shrinidhi.kaushik@gmail.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-01format-patch: teach format.useAutoBase "whenAble" optionJacob Keller
The format.useAutoBase configuration option exists to allow users to enable '--base=auto' for format-patch by default. This can sometimes lead to poor workflow, due to unexpected failures when attempting to format an ancient patch: $ git format-patch -1 <an old commit> fatal: base commit shouldn't be in revision list This can be very confusing, as it is not necessarily immediately obvious that the user requested a --base (since this was in the configuration, not on the command line). We do want --base=auto to fail when it cannot provide a suitable base, as it would be equally confusing if a formatted patch did not include the base information when it was requested. Teach format.useAutoBase a new mode, "whenAble". This mode will cause format-patch to attempt to include a base commit when it can. However, if no valid base commit can be found, then format-patch will continue formatting the patch without a base commit. In order to avoid making yet another branch name unusable with --base, do not teach --base=whenAble or --base=whenable. Instead, refactor the base_commit option to use a callback, and rely on the global configuration variable auto_base. This does mean that a user cannot request this optional base commit generation from the command line. However, this is likely not too valuable. If the user requests base information manually, they will be immediately informed of the failure to acquire a suitable base commit. This allows the user to make an informed choice about whether to continue the format. Add tests to cover the new mode of operation for --base. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-01submodule update: silence underlying merge/rebase with "--quiet"Theodore Dubois
Commands such as $ git pull --rebase --recurse-submodules --quiet produce non-quiet output from the merge or rebase. Pass the --quiet option down when invoking "rebase" and "merge". Also fix the parsing of git submodule update -v. When e84c3cf3 (git-submodule.sh: accept verbose flag in cmd_update to be non-quiet, 2018-08-14) taught "git submodule update" to take "--quiet", it apparently did not know how ${GIT_QUIET:+--quiet} works, and reviewers seem to have missed that setting the variable to "0", rather than unsetting it, still results in "--quiet" being passed to underlying commands. Signed-off-by: Theodore Dubois <tbodt@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30refspec: add support for negative refspecsJacob Keller
Both fetch and push support pattern refspecs which allow fetching or pushing references that match a specific pattern. Because these patterns are globs, they have somewhat limited ability to express more complex situations. For example, suppose you wish to fetch all branches from a remote except for a specific one. To allow this, you must setup a set of refspecs which match only the branches you want. Because refspecs are either explicit name matches, or simple globs, many patterns cannot be expressed. Add support for a new type of refspec, referred to as "negative" refspecs. These are prefixed with a '^' and mean "exclude any ref matching this refspec". They can only have one "side" which always refers to the source. During a fetch, this refers to the name of the ref on the remote. During a push, this refers to the name of the ref on the local side. With negative refspecs, users can express more complex patterns. For example: git fetch origin refs/heads/*:refs/remotes/origin/* ^refs/heads/dontwant will fetch all branches on origin into remotes/origin, but will exclude fetching the branch named dontwant. Refspecs today are commutative, meaning that order doesn't expressly matter. Rather than forcing an implied order, negative refspecs will always be applied last. That is, in order to match, a ref must match at least one positive refspec, and match none of the negative refspecs. This is similar to how negative pathspecs work. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30combine-diff: handle --find-object in multitree code pathJeff King
When doing combined diffs, we have two possible code paths: - a slower one which independently diffs against each parent, applies any filters, and then intersects the resulting paths - a faster one which walks all trees simultaneously When the diff options specify that we must do certain filters, like pickaxe, then we always use the slow path, since the pickaxe code only knows how to handle filepairs, not the n-parent entries generated for combined diffs. But there are two problems with the slow path: 1. It's slow. Running: git rev-list HEAD | git diff-tree --stdin -r -c in git.git takes ~3s on my machine. But adding "--find-object" to that increases it to ~6s, even though find-object itself should incur only a few extra oid comparisons. On linux.git, it's even worse: 35s versus 215s. 2. It doesn't catch all cases where a particular path is interesting. Consider a merge with parent blobs X and Y for a particular path, and end result Z. That should be interesting according to "-c", because the result doesn't match either parent. And it should be interesting even with "--find-object=X", because "X" went away in the merge. But because we perform each pairwise diff independently, this confuses the intersection code. The change from X to Z is still interesting according to --find-object. But in the other parent we went from Y to Z, so the diff appears empty! That causes the intersection code to think that parent didn't change the path, and thus it's not interesting for "-c". This patch fixes both by implementing --find-object for the multitree code. It's a bit unfortunate that we have to duplicate some logic from diffcore-pickaxe, but this is the best we can do for now. In an ideal world, all of the diffcore code would stop thinking about filepairs and start thinking about n-parent sets, and we could use the multitree walk with all of it. Until then, there are some leftover warts: - other pickaxe operations, like -S or -G, still suffer from both problems. These would be hard to adapt because they rely on having a diff_filespec() for each path to look at content. And we'd need to define what an n-way "change" means in each case (probably easy for "-S", which can compare counts, but not so clear for -G, which is about grepping diffs). - other options besides --find-object may cause us to use the slow pairwise path, in which case we'll go back to producing a different (wrong) answer for the X/Y/Z case above. We may be able to hack around these, but I think the ultimate solution will be a larger rewrite of the diffcore code. For now, this patch improves one specific case but leaves the rest. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30hashmap_for_each_entry(): workaround MSVC's runtime check failure #3Junio C Hamano
The OFFSETOF_VAR(var, member) macro is implemented in terms of offsetof(typeof(*var), member) with compilers that know typeof(), but its fallback implemenation compares &(var->member) and (var) and count the distance in bytes, i.e. ((uintptr_t)&(var)->member - (uintptr_t)(var)) MSVC's runtime check, when fed an uninitialized 'var', flags this as a use of an uninitialized variable (and that is legit---uninitialized contents of 'var' is subtracted) in a debug build. After auditing all 6 uses of OFFSETOF_VAR(), 1 of them does feed a potentially uninitialized 'var' to the macro in the beginning of the for() loop: #define hashmap_for_each_entry(map, iter, var, member) \ for (var = hashmap_iter_first_entry_offset(map, iter, \ OFFSETOF_VAR(var, member)); \ var; \ var = hashmap_iter_next_entry_offset(iter, \ OFFSETOF_VAR(var, member))) We can work around this by making sure that var has _some_ value when OFFSETOF_VAR() is called. Strictly speaking, it invites undefined behaviour to use NULL here if we end up with pointer comparison, but MSVC runtime seems to be happy with it, and most other systems have typeof() and don't even need pointer comparison fallback code. Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake (Windows): recommend using Visual Studio's built-in CMake supportJohannes Schindelin
It is a lot more convenient to use than having to specify the configuration in CMake manually (does not matter whether using the command-line or CMake's GUI). While at it, recommend using `contrib/buildsystems/out/` as build directory also in the part that talks about running CMake manually. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake (Windows): initialize vcpkg/build dependencies automaticallyJohannes Schindelin
The idea of having CMake support in Git's source tree is to enable contributors on Windows to start contributing with little effort. To that end, we just added some sensible defaults that will let users open the worktree in Visual Studio and start building. This expects the dependencies (such as zlib) to be available already, though. If they are not available, we expect the user to run `compat/vcbuild/vcpkg_install.bat`. Rather than requiring this step to be manual, detect the situation and run it as part of the CMake configuration step. Note that this obviously only applies to the scenario when we want to compile in Visual Studio (i.e. with MS Visual C), not with GCC. Therefore, we guard this new code block behind the `MSVC` conditional. This concludes our journey to make it as effortless as possible to start developing Git in Visual Studio: all the developer needs to do is to clone Git's repository, open the worktree via `File>Open>Folder...` and wait for CMake to finish configuring. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake (Windows): complain when encountering an unknown compilerJohannes Schindelin
We have some custom handling regarding the link options, which are specific to each compiler. Therefore: let's not just continue without setting the link options if configuring for a currently unhandled compiler, but error out. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake (Windows): let the `.dll` files be found when running the testsJohannes Schindelin
Contrary to Unix-ish platforms, the dependencies' shared libraries are not usually found in one central place. In our case, since we use `vcpkg`, they are to be found inside the `compat/vcbuild/vcpkg/` tree. Let's make sure that they are in the search path when running the tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake: quote the path accurately when editing `test-lib.sh`Johannes Schindelin
By default, the build directory will be called something like `contrib/buildsystems/out/build/x64-Debug (default)` (note the space and the parentheses). We need to make sure that such a path is quoted properly when editing the assignment of the `GIT_BUILD_DIR` variable. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake: fall back to using `vcpkg`'s `msgfmt.exe` on WindowsJohannes Schindelin
We are already relying on `vcpkg` to manage our dependencies, including `libiconv`. Let's also use the `msgfmt.exe` from there. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30dir.c: drop unused "untracked" from treat_path_fast()Jeff King
We don't use the untracked_cache_dir parameter that is passed in, but instead look at the untracked_cache_dir inside the cached_dir struct we are passed. It's been this way since the introduction of treat_path_fast() in 91a2288b5f (untracked cache: record/validate dir mtime and reuse cached output, 2015-03-08). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30sequencer: handle ignore_footer when parsing trailersJeff King
The append_signoff() function takes an "ignore_footer" argument, which specifies a number of bytes at the end of the message buffer which should not be considered (they cannot contain trailers, and the trailer is spliced in before them). But to find the existing trailers, it calls into has_conforming_trailer(). That function takes an ignore_footer parameter, but since 967dfd4d56 (sequencer: use trailer's trailer layout, 2016-11-02) the parameter is completely ignored. The trailer interface we're using takes a single string, with no option to tell it to use part of the string. However, since we have a mutable strbuf, we can work around this by simply overwriting (and later restoring) the boundary with a NUL. I'm not sure if this can actually trigger a bug in practice. It's easy to get a non-zero ignore_footer by doing something like this: git commit -F - --cleanup=verbatim <<-EOF subject body Signed-off-by: me # this looks like a comment, but is actually in the # message! That makes the earlier s-o-b fake. EOF git commit --amend -s There git-commit calls ignore_non_trailer() to count up the "#" cruft, which becomes the ignore_footer header. But it works even without this patch! That's because the trailer code _also_ calls ignore_non_trailer() and skips the cruft, too. So it happens to work because the only callers with a non-zero ignore_footer are using the exact same function that the trailer parser uses internally. And that seems true for all of the current callers, but there's nothing guaranteeing it. We're better off only feeding the correct buffer to the trailer code in the first place. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30test-advise: check argument count with argc instead of argvJeff King
We complain if "test-tool advise" is not given an argument, but we quietly ignore any additional arguments it receives. Let's instead check that we got the expected number. As a bonus, this silences -Wunused-parameter, which notes that we don't ever look at argc. While we're here, we can also fix the indentation in the conditional. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30sparse-checkout: fill in some options boilerplateJeff King
The sparse-checkout passes along argv and argc to its sub-command helper functions. Many of these sub-commands do not yet take any command-line options, and ignore those parameters. Let's instead add empty option lists and make sure we call parse_options(). That will give a useful error message for something like: git sparse-checkout list --nonsense which currently just silently ignores the unknown option. As a bonus, it also silences some -Wunused-parameter warnings. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30sequencer: drop repository argument from run_git_commit()Jeff King
When we switched to using an external git-commit call in b0a3186140 (sequencer: simplify root commit creation, 2019-08-19), this function didn't need to care about the repository object any more. Arguably we could be passing along the repository path to the external git-commit by using "--git-dir=r->path" here. But for the most part the sequencer code relies on sub-process finding the same repository we're already in (using the same environment variables or discovery process we did). But we don't have a convenient interface for doing so, and there's no indication that we need to. Let's just drop the unused parameter for now. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30push: drop unused repo argument to do_push()Jeff King
We stopped using the "repo" argument in 8e4c8af058 (push: disallow --all and refspecs when remote.<name>.mirror is set, 2019-09-02), which moved the pushremote handling to its caller. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30assert PARSE_OPT_NONEG in parse-options callbacksJeff King
In the spirit of 517fe807d6 (assert NOARG/NONEG behavior of parse-options callbacks, 2018-11-05), let's cover some parse-options callbacks which expect to be used with PARSE_OPT_NONEG but don't explicitly assert that this is the case. These callbacks are all used correctly in the current code, but this will help document their expectations and future-proof the code. As a bonus, it also silences -Wunused-parameters (these were added since the initial sweep of 517fe807d6, and we can't yet turn on -Wunused-parameters to remind people because it has too many existing false positives). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30env--helper: write to opt->value in parseopt helperJeff King
We use OPT_CALLBACK_F() to call the option_parse_type() callback, passing it the address of "cmdmode" as the value to write to. But the callback doesn't look at opt->value at all, and instead writes to a global variable. This works out because that's the same global variable we happen to pass in, but it's rather confusing. Let's use the passed-in value instead. We'll also make "cmdmode" a local variable of the main function, ensuring we can't make the same mistake again. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30drop unused argc parametersJeff King
Many functions take an argv/argc pair, but never actually look at argc. This makes it useless at best (we use the NULL sentinel in argv to find the end of the array), and misleading at worst (what happens if the argc count does not match the argv NULL?). In each of these instances, the argv NULL does match the argc count, so there are no bugs here. But let's tighten the interfaces to make it harder to get wrong (and to reduce some -Wunused-parameter complaints). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30convert: drop unused crlf_action from check_global_conv_flags_eol()Jeff King
The crlf_action parameter hasn't been used since a0ad53c181 (convert: Correct NNO tests and missing `LF will be replaced by CRLF`, 2016-08-13), where that part of the function was hoisted out to a separate will_convert_lf_to_crlf() helper. Let's drop the useless parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-29Eighteenth batchJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-29Merge branch 'ah/pull'Junio C Hamano
Earlier we taught "git pull" to warn when the user does not say the histories need to be merged, rebased or accepts only fast- forwarding, but the warning triggered for those who have set the pull.ff configuration variable. * ah/pull: pull: don't warn if pull.ff has been set
2020-09-29Merge branch 'tg/range-diff-same-file-fix'Junio C Hamano
"git range-diff" showed incorrect diffstat, which has been corrected. * tg/range-diff-same-file-fix: diff: fix modified lines stats with --stat and --numstat
2020-09-29Merge branch 'jc/t1506-rev-parse-leaves-range-endpoint-unpeeled'Junio C Hamano
Test update. * jc/t1506-rev-parse-leaves-range-endpoint-unpeeled: t1506: rev-parse A..B and A...B
2020-09-29Merge branch 'dl/zero-oid-in-hooks'Junio C Hamano
Adjust sample hooks for hash algorithm other than SHA-1. * dl/zero-oid-in-hooks: hooks--update.sample: use hash-agnostic zero OID hooks--pre-push.sample: use hash-agnostic zero OID hooks--pre-push.sample: modernize script
2020-09-29Merge branch 'jk/make-protocol-v2-the-default'Junio C Hamano
The transport protocol v2 has become the default again. * jk/make-protocol-v2-the-default: protocol: re-enable v2 protocol by default
2020-09-29Merge branch 'bc/clone-with-git-default-hash-fix'Junio C Hamano
"git clone" that clones from SHA-1 repository, while GIT_DEFAULT_HASH set to use SHA-256 already, resulted in an unusable repository that half-claims to be SHA-256 repository with SHA-1 objects and refs. This has been corrected. * bc/clone-with-git-default-hash-fix: builtin/clone: avoid failure with GIT_DEFAULT_HASH
2020-09-29Merge branch 'tb/bloom-improvements'Junio C Hamano
"git commit-graph write" learned to limit the number of bloom filters that are computed from scratch with the --max-new-filters option. * tb/bloom-improvements: commit-graph: introduce 'commitGraph.maxNewFilters' builtin/commit-graph.c: introduce '--max-new-filters=<n>' commit-graph: rename 'split_commit_graph_opts' bloom: encode out-of-bounds filters as non-empty bloom/diff: properly short-circuit on max_changes bloom: use provided 'struct bloom_filter_settings' bloom: split 'get_bloom_filter()' in two commit-graph.c: store maximum changed paths commit-graph: respect 'commitGraph.readChangedPaths' t/helper/test-read-graph.c: prepare repo settings commit-graph: pass a 'struct repository *' in more places t4216: use an '&&'-chain commit-graph: introduce 'get_bloom_filter_settings()'
2020-09-29Merge branch 'bc/faq-misc'Junio C Hamano
More FAQ entries. * bc/faq-misc: docs: explain how to deal with files that are always modified docs: explain why reverts are not always applied on merge docs: explain why squash merges are broken with long-running branches
2020-09-29diff: get rid of redundant 'dense' argumentSergey Organov
Get rid of 'dense' argument that is redundant for every function that has 'struct rev_info *rev' argument as well, as the value of 'dense' passed is always taken from 'rev->dense_combined_merges' field. The only place where this was not the case is in 'submodule.c' where 'diff_tree_combined_merge()' was called with '1' for 'dense' argument. However, at that call the 'revs' instance used is local to the function, and we now just set 'revs->dense_combined_merges' to 1 in this local instance. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-29packfile: fix memory leak in add_delta_base_cache()Matheus Tavares
When add_delta_base_cache() is called with a base that is already in the cache, no operation is performed. But the check is done after allocating space for a new entry, so we end up leaking memory on the early return. In addition, the caller never free()'s the base as it expects the function to take ownership of it. But the base is not released when we skip insertion, so it also gets leaked. To fix these problems, move the allocation of a new entry further down in add_delta_base_cache(), and free() the base on early return. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-29packfile: fix race condition on unpack_entry()Matheus Tavares
The third phase of unpack_entry() performs the following sequence in a loop, until all the deltas enumerated in phase one are applied and the entry is fully reconstructed: 1. Add the current base entry to the delta base cache 2. Unpack the next delta 3. Patch the unpacked delta on top of the base When the optional object reading lock is enabled, the above steps will be performed while holding the lock. However, step 2. momentarily releases it so that inflation can be performed in parallel for increased performance. Because the `base` buffer inserted in the cache at 1. is not duplicated, another thread can potentially free() it while the lock is released at 2. (e.g. when there is no space left in the cache to insert another entry). In this case, the later attempt to dereference `base` at 3. will cause a segmentation fault. This problem was observed during a multithreaded git-grep execution on a repository with large objects. To fix the race condition (and later segmentation fault), let's reorder the aforementioned steps so that `base` is only added to the cache at the end. This will prevent the buffer from being released by another thread while it is still in use. An alternative solution which would not require the reordering would be to duplicate `base` before inserting it in the cache. However, as Phil Hord mentioned, memcpy()'ing large bases can negatively affect performance: in his experiments, this alternative approach slowed git-grep down by 10% to 20%. Reported-by: Phil Hord <phil.hord@gmail.com> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>