summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-10-08ci: do not skip tagged revisions in GitHub workflowsLibravatar Johannes Schindelin1-0/+2
When `master` is tagged, and then both `master` and the tag are pushed, Travis CI will happily build both. That is a waste of energy, which is why we skip the build for `master` in that case. Our GitHub workflow is also triggered by tags. However, the run would fail because the `windows-test` jobs are _not_ skipped on tags, but the `windows-build` job _is skipped (and therefore fails to upload the build artifacts needed by the test jobs). In addition, we just added logic to our GitHub workflow that will skip runs altogether if there is already a successful run for the same commit or at least for the same tree. Let's just change the GitHub workflow to no longer specifically skip tagged revisions. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08ci: skip GitHub workflow runs for already-tested commits/treesLibravatar Johannes Schindelin1-1/+38
When pushing a commit that has already passed a CI or PR build successfully, it makes sense to save some energy and time and skip the new build. Let's teach our GitHub workflow to do that. For good measure, we also compare the tree ID, which is what we actually test (the commit ID might have changed due to a reworded commit message, which should not affect the outcome of the run). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-05Git 2.29-rc0Libravatar Junio C Hamano2-1/+32
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-05Merge branch 'nl/credential-crlf'Libravatar Junio C Hamano1-1/+1
Loosen the parser in the receiving end of the credential protocol to allow credential helper to terminate lines with CRLF line ending, as well as LF line ending. * nl/credential-crlf: credential: treat CR/LF as line endings in the credential protocol
2020-10-05Merge branch 'sn/fast-import-doc'Libravatar Junio C Hamano1-1/+1
Doc update. * sn/fast-import-doc: fast-import: fix typo in documentation
2020-10-05Merge branch 'pb/submodule-doc-fix'Libravatar Junio C Hamano1-10/+13
Doc update. * pb/submodule-doc-fix: gitsubmodules doc: invoke 'ls-files' with '--recurse-submodules'
2020-10-05Merge branch 'jk/format-auto-base-when-able'Libravatar Junio C Hamano3-26/+130
"git format-patch" learns to take "whenAble" as a possible value for the format.useAutoBase configuration variable to become no-op when the automatically computed base does not make sense. * jk/format-auto-base-when-able: format-patch: teach format.useAutoBase "whenAble" option
2020-10-05Merge branch 'jk/diff-cc-oidfind-fix'Libravatar Junio C Hamano2-2/+96
"log -c --find-object=X" did not work well to find a merge that involves a change to an object X from only one parent. * jk/diff-cc-oidfind-fix: combine-diff: handle --find-object in multitree code path
2020-10-05Merge branch 'jk/refspecs-negative'Libravatar Junio C Hamano7-13/+367
"git fetch" and "git push" support negative refspecs. * jk/refspecs-negative: refspec: add support for negative refspecs
2020-10-05Merge branch 'rs/archive-add-file'Libravatar Junio C Hamano8-71/+203
"git archive" learns the "--add-file" option to include untracked files into a snapshot from a tree-ish. * rs/archive-add-file: Makefile: use git-archive --add-file archive: add --add-file archive: read short blobs in archive.c::write_archive_entry()
2020-10-05Merge branch 'jt/keep-partial-clone-filter-upon-lazy-fetch'Libravatar Junio C Hamano5-9/+13
The lazy fetching done internally to make missing objects available in a partial clone incorrectly made permanent damage to the partial clone filter in the repository, which has been corrected. * jt/keep-partial-clone-filter-upon-lazy-fetch: fetch: do not override partial clone filter promisor-remote: remove unused variable
2020-10-05Merge branch 'td/submodule-update-quiet'Libravatar Junio C Hamano2-3/+15
"git submodule update --quiet" did not squelch underlying "rebase" and "pull" commands. * td/submodule-update-quiet: submodule update: silence underlying merge/rebase with "--quiet"
2020-10-05Merge branch 'jk/unused'Libravatar Junio C Hamano15-33/+88
Code cleanup. * jk/unused: dir.c: drop unused "untracked" from treat_path_fast() sequencer: handle ignore_footer when parsing trailers test-advise: check argument count with argc instead of argv sparse-checkout: fill in some options boilerplate sequencer: drop repository argument from run_git_commit() push: drop unused repo argument to do_push() assert PARSE_OPT_NONEG in parse-options callbacks env--helper: write to opt->value in parseopt helper drop unused argc parameters convert: drop unused crlf_action from check_global_conv_flags_eol()
2020-10-05Merge branch 'js/cmake-vs'Libravatar Junio C Hamano3-13/+43
Using the CMake support we added some time ago for real with Visual Studio build revealed there were lot of usability improvements possible, which have been carried out. * js/cmake-vs: hashmap_for_each_entry(): workaround MSVC's runtime check failure #3 cmake (Windows): recommend using Visual Studio's built-in CMake support cmake (Windows): initialize vcpkg/build dependencies automatically cmake (Windows): complain when encountering an unknown compiler cmake (Windows): let the `.dll` files be found when running the tests cmake: quote the path accurately when editing `test-lib.sh` cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows cmake: ensure that the `vcpkg` packages are found on Windows cmake: do find Git for Windows' shell interpreter cmake: ignore files generated by CMake as run in Visual Studio
2020-10-05Merge branch 'ma/worktree-cleanups'Libravatar Junio C Hamano5-66/+70
Code clean-up. * ma/worktree-cleanups: worktree: use skip_prefix to parse target worktree: rename copy-pasted variable worktree: update renamed variable in comment worktree: inline `worktree_ref()` into its only caller wt-status: introduce wt_status_state_free_buffers() wt-status: print to s->fp, not stdout wt-status: replace sha1 mentions with oid
2020-10-05Merge branch 'so/combine-diff-simplify'Libravatar Junio C Hamano6-23/+18
Code simplification. * so/combine-diff-simplify: diff: get rid of redundant 'dense' argument
2020-10-05Merge branch 'js/default-branch-name-part-2'Libravatar Junio C Hamano11-97/+97
Update the tests to drop word 'master' from them. * js/default-branch-name-part-2: t9902: avoid using the branch name `master` tests: avoid variations of the `master` branch name t3200: avoid variations of the `master` branch name fast-export: avoid using unnecessary language in a code comment t/test-terminal: avoid non-inclusive language
2020-10-05Merge branch 'pm/gitk-update'Libravatar Junio C Hamano1-5311/+5343
"gitk" update. * pm/gitk-update: 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-05Merge branch 'ds/in-merge-bases-many-optim-bug'Libravatar Junio C Hamano3-4/+36
in_merge_bases_many(), a way to see if a commit is reachable from any commit in a set of commits, was totally broken when the commit-graph feature was in use, which has been corrected. * ds/in-merge-bases-many-optim-bug: commit-reach: fix in_merge_bases_many bug
2020-10-04fast-import: fix typo in documentationLibravatar Samanta Navarro1-1/+1
Signed-off-by: Samanta Navarro <ferivoz@riseup.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-04gitsubmodules doc: invoke 'ls-files' with '--recurse-submodules'Libravatar Philippe Blain1-10/+13
`git ls-files` was never taught to respect the `submodule.recurse` configuration variable, and it is too late now to change that [1], but still the command is mentioned in 'gitsubmodules(7)' as if it does respect that config. Adjust the call in 'gitsubmodules(7)' by calling 'ls-files' with the '--recurse-submodules' option. While at it, uniformize the capitalization in that file, and use backticks instead of quotes for Git commands and configuration variables. [1] https://lore.kernel.org/git/pull.732.git.1599707259907.gitgitgadget@gmail.com/T/#u Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-04Nineteenth batchLibravatar Junio C Hamano1-0/+33
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-04Merge branch 'mt/delta-base-cache-races'Libravatar Junio C Hamano1-19/+29
A race that leads to an access to a free'd data was corrected in the codepath that reads pack files. * mt/delta-base-cache-races: packfile: fix memory leak in add_delta_base_cache() packfile: fix race condition on unpack_entry()
2020-10-04Merge branch 'jk/shortlog-group-by-trailer'Libravatar Junio C Hamano7-31/+444
"git shortlog" has been taught to group commits by the contents of the trailer lines, like "Reviewed-by:", "Coauthored-by:", etc. * jk/shortlog-group-by-trailer: shortlog: allow multiple groups to be specified shortlog: parse trailer idents shortlog: rename parse_stdin_ident() shortlog: de-duplicate trailer values shortlog: match commit trailers with --group trailer: add interface for iterating over commit trailers shortlog: add grouping option shortlog: change "author" variables to "ident"
2020-10-04Merge branch 'jc/fmt-merge-msg-suppress-destination'Libravatar Junio C Hamano1-1/+1
Docfix. * jc/fmt-merge-msg-suppress-destination: config/fmt-merge-msg.txt: drop space in quote
2020-10-04Merge branch 'tb/upload-pack-filters'Libravatar Junio C Hamano1-1/+1
Hotfix. * tb/upload-pack-filters: config/uploadpack.txt: fix typo in `--filter=tree:<n>`
2020-10-04Merge branch 'jc/sequencer-stopped-sha-simplify'Libravatar Junio C Hamano1-5/+6
Code simplification. * jc/sequencer-stopped-sha-simplify: sequencer: stop abbreviating stopped-sha file
2020-10-04Merge branch 'au/complete-restore-s'Libravatar Junio C Hamano1-34/+39
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'Libravatar Junio C Hamano1-1/+3
Hotfix. * al/ref-filter-merged-and-no-merged: ref-filter: plug memory leak in reach_filter()
2020-10-04Merge branch 'eg/mailinfo-doc-scissors'Libravatar Junio C Hamano1-4/+3
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'Libravatar Junio C Hamano3-78/+274
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'Libravatar Junio C Hamano2-7/+13
"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'Libravatar Junio C Hamano4-25/+81
"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'Libravatar Junio C Hamano3-29/+4
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'Libravatar Junio C Hamano2-27/+40
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'Libravatar Junio C Hamano13-401/+169
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 protocolLibravatar Nikita Leonov1-1/+1
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-updateLibravatar Junio C Hamano1-5311/+5343
* 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 sizeLibravatar Paul Mackerras1-4/+11
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 spacesLibravatar Denton Liu1-5308/+5308
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 bugLibravatar Derrick Stolee3-4/+36
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" optionLibravatar Jacob Keller3-26/+130
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"Libravatar Theodore Dubois2-3/+15
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 refspecsLibravatar Jacob Keller7-13/+367
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 pathLibravatar Jeff King2-2/+96
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 #3Libravatar Junio C Hamano1-1/+2
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 supportLibravatar Johannes Schindelin1-9/+17
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 automaticallyLibravatar Johannes Schindelin1-0/+4
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 compilerLibravatar Johannes Schindelin1-0/+2
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 testsLibravatar Johannes Schindelin1-0/+3
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>