summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorLines
2024-07-18git-svn: use `svn:global-ignores` to create .gitignoreAlex Galvin-14/+31
`svn:global-ignores` contains a list of file patterns that should not be tracked in version control. The syntax of these patterns is the same as `svn:ignore`. Their semantics differ: patterns in `svn:global-ignores` apply to all paths under the directory where they apply, while `svn:ignore` only applies to the directory's immediate children. Signed-off-by: Alex Galvin <agalvin@comqi.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-18git-svn: add public property `svn:global-ignores`Alex Galvin-1/+1
Subversion 1.8 added a new property `svn:global-ignores`. It contains a list of patterns used to determine what files should be ignored. If Git-SVN is going to ignore these files as well, it is important that we do not skip over directories that have this property set. Signed-off-by: Alex Galvin <agalvin@comqi.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-18t5319: add failing test case for repack/expireDerrick Stolee-0/+55
Git 2.45.0 included the change b7d6f23a171 (midx-write.c: use `--stdin-packs` when repacking, 2024-04-01) which caused the 'git multi-pack-index repack' command to use 'git pack-objects --stdin-packs' instead of listing the objects to repack. While this change was motivated by efficient cross-process communication and the ability to improve delta compression, it breaks a fundamental function of the 'incremental-repack' task that is enabled by default in Scalar clones or Git repositories that run 'git maintenance start'. The 'incremental-repack' task performs a two-step process of the 'expire' and 'repack' subcommands of the 'git multi-pack-index' builtin. The 'expire' command removes any pack-files listed in the multi-pack-index but without any referenced objects. The 'repack' task then finds a batch of pack-files to repack and sends their objects to 'git pack-objects'. Both the pack-files chosen for the batch and the objects chosen to repack are based on the ones that the multi-pack-index references. Objects that appear in a pack-file but have a duplicate copy in a newer pack-file are not considered in this case. Since the multi-pack-index references only the newest copy of an object, this allows the next 'incremental-repack' task to remove the pack-files in the next 'expire' task. This delay is intentional due to how Windows handles may block deletion of files with open read handles. However, the mentioned commit changed this behavior to divorce the set of objects referenced by the multi-pack-index and instead use a set of "included" and "excluded" pack-files in the 'git pack-objects' builtin. When a pack-file is selected as "included", only the objects it contains but are not in any "excluded" pack-files are considered for repacking. This has led to client repositories failing to remove old pack-files as they still have some referenced objects. This grows over time until the point that Git is trying to repack the same pack-files over and over. For now, create a test case that demonstrates the expected behavior, but also fails in its final line. The setup here it attempting to recreate a typical situation for a repository that uses a blobless partial clone. There would be a large initial pack-file from the clone that is never selected in the 'repack' batch. There are other pack-files that have a combination of new objects from incremental fetches and possibly blobs that are not connected to those incremental fetches; these blobs could be filled in from commands like 'git checkout' or 'git blame'. The pack-files also have some overlap on purpose so test-1 has some duplicates in test-2 and test-2 has some duplicates in test-3. At the end of the test, the test-2 pack-file still exists though it should have been expired. This test will pass when reverting the offending commit. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-18Git 2.46-rc1v2.46.0-rc1Junio C Hamano-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-18Merge branch 'jk/am-retry'Junio C Hamano-1/+1
Test fix as a follow-up to an already graduated topic. * jk/am-retry: t4153: stop redirecting input from /dev/zero
2024-07-18Merge branch 'tb/pseudo-merge-reachability-bitmap'Junio C Hamano-4/+10
Doc update. * tb/pseudo-merge-reachability-bitmap: Documentation/gitpacking: make sample configs listing blocks
2024-07-18Merge branch 'ps/pseudo-ref-terminology'Junio C Hamano-1/+1
Doc update. * ps/pseudo-ref-terminology: Documentation/glossary: fix double word
2024-07-18Merge branch 'tb/doc-max-tree-depth-fix'Junio C Hamano-1/+2
Doc update. * tb/doc-max-tree-depth-fix: Documentation: fix default value for core.maxTreeDepth
2024-07-18Merge branch 'ch/refs-without-the-repository-fix'Junio C Hamano-2/+2
Comment fix. * ch/refs-without-the-repository-fix: refs: correct the version numbers in a comment
2024-07-18config.mak.uname: remove unused uname_P variableRamsay Jones-1/+0
The uname_P make variable was added in commit e15f545155 ("Makefile tweaks: Solaris 9+ dont need iconv / move up uname variables", 2006-02-20), but it seems to never have been used (even in that original commit). The man page for 'uname' notes that the '-p' processor option is non-portable (the 'uname_M' variable is used by the Makefile for that purpose). Remove the unused 'uname_P' make variable. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-18Makefile: drop -Wno-universal-initializer from SP_EXTRA_FLAGSRamsay Jones-1/+1
Commit 1c96642326 ("sparse: allow '{ 0 }' to be used without warnings", 2020-05-22) added -Wno-universal-initializer to the SP_EXTRA_FLAGS in order to suppress potential sparse warnings from using '{0}' as an aggregate initializer. At that time, the default was for sparse to issue warnings (i.e. the default was -Wuniversal-initializer) if such an initializer was used to initialize an aggregate whose first member was a pointer type. However, this default was changed just a few days later to -Wno-universal-initializer (first released in sparse v0.6.2) and has been so in all subsequent release versions of sparse. Thus, including -Wno-universal-initializer in the SP_EXTRA_FLAGS variable is redundant. Remove the unnecessary warning flag from SP_EXTRA_FLAGS, essentially reverting commit 1c96642326. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-17Post 2.46-rc0 batch #3Junio C Hamano-0/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-17Merge branch 'js/unit-test-oidtree-cmake-fix'Junio C Hamano-1/+2
Build fix. * js/unit-test-oidtree-cmake-fix: cmake: fix build of `t-oidtree`
2024-07-17Merge branch 'js/var-git-shell-path'Junio C Hamano-13/+78
"git var GIT_SHELL_PATH" should report the path to the shell used to spawn external commands, but it didn't do so on Windows, which has been corrected. * js/var-git-shell-path: var(win32): do report the GIT_SHELL_PATH that is actually used run-command: declare the `git_shell_path()` function globally run-command(win32): resolve the path to the Unix shell early mingw(is_msys2_sh): handle forward slashes in the `sh.exe` path, too win32: override `fspathcmp()` with a directory separator-aware version strvec: declare the `strvec_push_nodup()` function globally run-command: refactor getting the Unix shell path into its own function
2024-07-17Merge branch 'ps/doc-http-empty-cookiefile'Junio C Hamano-1/+5
What happens when http.cookieFile gets the special value "" has been clarified in the documentation. * ps/doc-http-empty-cookiefile: doc: update http.cookieFile with in-memory cookie processing
2024-07-17Merge branch 'kn/push-empty-fix'Junio C Hamano-14/+24
"git push '' HEAD:there" used to hit a BUG(); it has been corrected to die with "fatal: bad repository ''". * kn/push-empty-fix: builtin/push: call set_refspecs after validating remote
2024-07-17Merge branch 'jc/http-cookiefile'Junio C Hamano-0/+9
The http.cookieFile and http.saveCookies configuration variables have a few values that need to be avoided, which are now ignored with warning messages. * jc/http-cookiefile: http.c: cookie file tightening
2024-07-17Merge branch 'jk/test-body-in-here-doc'Junio C Hamano-1026/+1286
The test framework learned to take the test body not as a single string but as a here-document. * jk/test-body-in-here-doc: t/.gitattributes: ignore whitespace in chainlint expect files t: convert some here-doc test bodies test-lib: allow test snippets as here-docs chainlint.pl: add tests for test body in heredoc chainlint.pl: recognize test bodies defined via heredoc chainlint.pl: check line numbers in expected output chainlint.pl: force CRLF conversion when opening input files chainlint.pl: do not spawn more threads than we have scripts chainlint.pl: only start threads if jobs > 1 chainlint.pl: add test_expect_success call to test snippets
2024-07-17Merge branch 'rj/test-sanitize-leak-log-fix'Junio C Hamano-47/+20
Tests that use GIT_TEST_SANITIZE_LEAK_LOG feature got their exit status inverted, which has been corrected. * rj/test-sanitize-leak-log-fix: test-lib: GIT_TEST_SANITIZE_LEAK_LOG enabled by default test-lib: fix GIT_TEST_SANITIZE_LEAK_LOG
2024-07-17Documentation: fix default value for core.maxTreeDepthTaylor Blau-1/+2
When `core.maxTreeDepth` was originally introduced via be20128bfa (add core.maxTreeDepth config, 2023-08-31), its default value was 4096. There have since been a couple of updates to its default value that were not reflected in the documentation for `core.maxTreeDepth`: - 4d5693ba05 (lower core.maxTreeDepth default to 2048, 2023-08-31) - b64d78ad02 (max_tree_depth: lower it for MSVC to avoid stack overflows, 2023-11-01) Commit 4d5693ba05 lowers the default to 2048 for platforms with smaller stack sizes, and commit b64d78ad02 lowers the default even further when Git is compiled with MSVC. Neither of these changes were reflected in the documentation, which I noticed while merging newer releases back into GitHub's private fork (which contained the original implementation of `core.maxTreeDepth`). Update the documentation to reflect what the platform-specific default values are. Noticed-by: Keith W. Campbell <keithc@ca.ibm.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-17Documentation/glossary: fix double wordMartin Ågren-1/+1
Remove a spurious "that". Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-17Documentation/gitpacking: make sample configs listing blocksMartin Ågren-4/+10
This document contains a few sample config snippets. At least with Asciidoctor, the section headers are rendered *more* indented than the variables that follow: [bitmapPseudoMerge "all"] pattern = "refs/" ... To address this, wrap these listings in AsciiDoc listing blocks. Remove the indentation from the section headings. This is similar to how we handle such sample config elsewhere, e.g., in config.txt. While we're here, fix the nearby "wiht" typo. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-17t4153: stop redirecting input from /dev/zeroJeff King-1/+1
Commit 852a171018 (am: let command-line options override saved options, 2015-08-04) redirected a few "git am" invocations from /dev/zero, even though it did not expect "am" to read the input. This was necessary at the time because those tests used test_terminal, and as described in 18d8c26930 (test_terminal: redirect child process' stdin to a pty, 2015-08-04): Note that due to the way the code is structured, the child's stdin pseudo-tty will be closed when we finish reading from our stdin. This means that in the common case, where our stdin is attached to /dev/null, the child's stdin pseudo-tty will be closed immediately. Some operations like isatty(), which git-am uses, require the file descriptor to be open, and hence if the success of the command depends on such functions, test_terminal's stdin should be redirected to a source with large amount of data to ensure that the child's stdin is not closed, e.g. test_terminal git am --3way </dev/zero But we later dropped the use of test_terminal in 53ce2e3f0a (am: add explicit "--retry" option, 2024-06-06). That commit dropped one of the redirections from /dev/zero but not the other. In theory the remaining one should not cause any problems, but it turns out that at least one platform (NonStop) does not have /dev/zero at all. We never noticed before because it also did not pass the TTY prereq, meaning these tests were not run at all there until 53ce2e3f0a. So let's drop the useless /dev/zero mention. There are others in the test suite, but they are run only for tests marked with EXPENSIVE (so not typically by default). Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-16Revert "reflog expire: don't use lookup_commit_reference_gently()"Junio C Hamano-1/+10
During Git 2.35 timeframe, daf1d828 (reflog expire: don't use lookup_commit_reference_gently(), 2021-12-22) replaced a call to lookup_commit_reference_gently() with a call to lookup_commit(). What it failed to consider was that our refs do not necessarily point at commits (most notably, we have annotated and signed tags), and more importantly that lookup_commit() does not dereference a tag to return a commit; instead it returns NULL when a tag is given. Since the commit returned is used as a starting point for the reachability check, this ejected the commits that are reachable only by an annotated tag out of the set of reachable commits, breaking the computation to correctly implement the "--expire-unreachable" option. We also started giving an error message that the API function expected to be fed a commit object. This problem hasn't been reported or noticed for a long time, probably because the "refs/tags/" hierarchy by default is not covered by reflogs, as nobody usually moves tags. Revert the change to correctly find the commit pointed at by the ref to restore the previous behaviour, but do so only in a more modern codebase, as we had significant code churn since then and it is not grave enough to worry about for older maintenance tracks. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-16Post 2.46-rc0 batch #2Junio C Hamano-0/+17
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-16Merge branch 'bc/gitfaq-more'Junio C Hamano-4/+110
A handful of entries are added to the GitFAQ document. * bc/gitfaq-more: doc: mention that proxies must be completely transparent gitfaq: add entry about syncing working trees gitfaq: give advice on using eol attribute in gitattributes gitfaq: add documentation on proxies
2024-07-16Merge branch 'bc/http-proactive-auth'Junio C Hamano-6/+192
The http transport can now be told to send request with authentication material without first getting a 401 response. * bc/http-proactive-auth: http: allow authenticating proactively
2024-07-16Merge branch 'jc/where-is-bash-for-ci'Junio C Hamano-1/+1
Shell script clean-up. * jc/where-is-bash-for-ci: ci: unify bash calling convention
2024-07-16Merge branch 'ds/advice-sparse-index-expansion'Junio C Hamano-1/+49
A new warning message is issued when a command has to expand a sparse index to handle working tree cruft that are outside of the sparse checkout. * ds/advice-sparse-index-expansion: advice: warn when sparse index expands
2024-07-16Merge branch 'cb/send-email-sanitize-trailer-addresses'Junio C Hamano-2/+45
Address-looking strings found on the trailer are now placed on the Cc: list after running through sanitize_address by "git send-email". * cb/send-email-sanitize-trailer-addresses: git-send-email: use sanitized address when reading mbox body
2024-07-16Merge branch 'en/ort-inner-merge-error-fix'Junio C Hamano-46/+165
The "ort" merge backend saw one bugfix for a crash that happens when inner merge gets killed, and assorted code clean-ups. * en/ort-inner-merge-error-fix: merge-ort: fix missing early return merge-ort: convert more error() cases to path_msg() merge-ort: upon merge abort, only show messages causing the abort merge-ort: loosen commented requirements merge-ort: clearer propagation of failure-to-function from merge_submodule merge-ort: fix type of local 'clean' var in handle_content_merge () merge-ort: maintain expected invariant for priv member merge-ort: extract handling of priv member into reusable function
2024-07-16t-strvec: fix type mismatch in check_strvecRené Scharfe-1/+2
Cast i from size_t to uintmax_t to match the format string. Reported-by: Jeff King <peff@peff.net> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-16refs: correct the version numbers in a commentChristian Hesse-2/+2
The paragraph talks about a change made in c8f815c2 (refs: remove functions without ref store, 2024-05-07), which is v2.46.0-rc0~119^2 and will be published as part of v2.46, not v2.45. Signed-off-by: Christian Hesse <mail@eworm.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-15doc: clarify post-receive hook behaviorJustin Tobler-6/+9
The `githooks` documentation mentions that the post-receive hook executes once after git-receive-pack(1) updates all references and that it also receives the same information as the pre-receive hook on standard input. This is misleading though because the hook only executes once if at least one of the attempted reference updates is successful. Also, while each line provided on standard input is in the same format as the pre-receive hook, the information received only includes the set of references that were successfully updated. Update the documentation to clarify these points and also provide a reference to the post-receive hook section of the `git-receive-pack` documentation which has additional information. Signed-off-by: Justin Tobler <jltobler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-15doc: note that AT&T ksh does not work with our test suiteJunio C Hamano-2/+2
The scripted Porcelain commands do not allow use of "local" because it is not universally supported, but we use it liberally in our test scripts, which means some POSIX compliant shells (like "ksh93") can not be used to run our tests. Document the status quo, to help the next person who gets perplexed seeing our tests fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-15Post 2.46-rc0 batch #1Junio C Hamano-1/+29
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-15Merge branch 'cp/unit-test-reftable-record'Junio C Hamano-384/+552
A test in reftable library has been rewritten using the unit test framework. * cp/unit-test-reftable-record: t-reftable-record: add tests for reftable_log_record_compare_key() t-reftable-record: add tests for reftable_ref_record_compare_name() t-reftable-record: add index tests for reftable_record_is_deletion() t-reftable-record: add obj tests for reftable_record_is_deletion() t-reftable-record: add log tests for reftable_record_is_deletion() t-reftable-record: add ref tests for reftable_record_is_deletion() t-reftable-record: add comparison tests for obj records t-reftable-record: add comparison tests for index records t-reftable-record: add comparison tests for ref records t-reftable-record: add reftable_record_cmp() tests for log records t: move reftable/record_test.c to the unit testing framework
2024-07-15Merge branch 'jc/disable-push-nego-for-deletion'Junio C Hamano-2/+21
"git push" that pushes only deletion gave an unnecessary and harmless error message when push negotiation is configured, which has been corrected. * jc/disable-push-nego-for-deletion: push: avoid showing false negotiation errors
2024-07-15Merge branch 'ri/doc-show-branch-fix'Junio C Hamano-1/+1
Docfix. * ri/doc-show-branch-fix: doc: fix the max number of branches shown by "show-branch"
2024-07-15Merge branch 'tb/dev-build-pedantic-fix'Junio C Hamano-1/+1
Developer build procedure fix. * tb/dev-build-pedantic-fix: config.mak.dev: fix typo when enabling -Wpedantic
2024-07-15Merge branch 'rs/clang-format-updates'Junio C Hamano-4/+9
Custom control structures we invented more recently have been taught to the clang-format file. * rs/clang-format-updates: clang-format: include kh_foreach* macros in ForEachMacros
2024-07-15Merge branch 'am/gitweb-feed-use-committer-date'Junio C Hamano-2/+2
GitWeb update to use committer date consistently in rss/atom feeds. * am/gitweb-feed-use-committer-date: gitweb: rss/atom change published/updated date to committer date
2024-07-15Merge branch 'jk/tests-without-dns'Junio C Hamano-7/+6
Test suite has been taught not to unnecessarily rely on DNS failing a bogus external name. * jk/tests-without-dns: t/lib-bundle-uri: use local fake bundle URLs t5551: do not confirm that bogus url cannot be used t5553: use local url for invalid fetch
2024-07-15Merge branch 'gt/unit-test-oidmap'Junio C Hamano-240/+182
An existing test of oidmap API has been rewritten with the unit-test framework. * gt/unit-test-oidmap: t: migrate helper/test-oidmap.c to unit-tests/t-oidmap.c
2024-07-15Merge branch 'as/describe-broken-refresh-index-fix'Junio C Hamano-0/+48
"git describe --dirty --broken" forgot to refresh the index before seeing if there is any chang, ("git describe --dirty" correctly did so), which has been corrected. * as/describe-broken-refresh-index-fix: describe: refresh the index when 'broken' flag is used
2024-07-15Merge branch 'rj/t0613-no-longer-leaks'Junio C Hamano-0/+1
A test that no longer leaks has been marked as such. * rj/t0613-no-longer-leaks: t0613: mark as leak-free
2024-07-15Merge branch 'rj/t0612-no-longer-leaks'Junio C Hamano-0/+1
A test that no longer leaks has been marked as such. * rj/t0612-no-longer-leaks: t0612: mark as leak-free
2024-07-15t-strvec: improve check_strvec() outputRené Scharfe-32/+14
The macro check_strvec calls the function check_strvec_loc(), which performs the actual checks. They report the line number inside that function on error, which is not very helpful. Before the previous patch half of them triggered an assertion that reported the caller's line number using a custom message, which was more useful, but a bit awkward. Improve the output by getting rid of check_strvec_loc() and performing all checks within check_strvec, as they then report the line number of the call site, aiding in finding the broken test. Determine the number of items and check it up front to avoid having to do them both in the loop and at the end. Sanity check the expected items to make sure there are any and that the last one is NULL, as the compiler no longer does that for us with the removal of the function attribute LAST_ARG_MUST_BE_NULL. Use only the actual strvec name passed to the macro, the internal "expect" array name and an index "i" in the output, for clarity. While "expect" does not exist at the call site, it's reasonably easy to infer that it's referring to the NULL-terminated list of expected strings, converted to an array. Here's the output with less items than expected in the strvec before: # check "vec->nr > nr" failed at t/unit-tests/t-strvec.c:19 # left: 1 # right: 1 ... and with the patch: # check "(&vec)->nr == ARRAY_SIZE(expect) - 1" failed at t/unit-tests/t-strvec.c:53 # left: 1 # right: 2 With too many items in the strvec we got before: # check "vec->nr == nr" failed at t/unit-tests/t-strvec.c:34 # left: 1 # right: 0 # check "vec->v[nr] == NULL" failed at t/unit-tests/t-strvec.c:36 # left: 0x6000004b8010 # right: 0x0 ... and with the patch: # check "(&vec)->nr == ARRAY_SIZE(expect) - 1" failed at t/unit-tests/t-strvec.c:53 # left: 1 # right: 0 A broken alloc value was reported like this: # check "vec->alloc > nr" failed at t/unit-tests/t-strvec.c:20 # left: 0 # right: 0 ... and with the patch: # check "(&vec)->nr <= (&vec)->alloc" failed at t/unit-tests/t-strvec.c:56 # left: 2 # right: 0 An unexpected string value was reported like this: # check "!strcmp(vec->v[nr], str)" failed at t/unit-tests/t-strvec.c:24 # left: "foo" # right: "bar" # nr: 0 ... and with the patch: # check "!strcmp((&vec)->v[i], expect[i])" failed at t/unit-tests/t-strvec.c:53 # left: "foo" # right: "bar" # i: 0 If the strvec is not NULL terminated, we got: # check "vec->v[nr] == NULL" failed at t/unit-tests/t-strvec.c:36 # left: 0x102c3abc8 # right: 0x0 ... and with the patch we get the line number of the caller: # check "!strcmp((&vec)->v[i], expect[i])" failed at t/unit-tests/t-strvec.c:53 # left: "bar" # right: NULL # i: 1 check_strvec calls without a trailing NULL were detected at compile time before: t/unit-tests/t-strvec.c:71:2: error: missing sentinel in function call [-Werror,-Wsentinel] ... and with the patch it's only found at runtime: # check "expect[ARRAY_SIZE(expect) - 1] == NULL" failed at t/unit-tests/t-strvec.c:53 # left: 0x100e5a663 # right: 0x0 We can let check_strvec add the terminating NULL for us and remove it from callers, making it impossible to forget. Leave that conversion for a future patch, though, since this reimplementation is already intrusive enough. Reported-by: Jeff King <peff@peff.net> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-13merge-recursive: honor diff.algorithmAntonin Delpeuch-15/+150
The documentation claims that "recursive defaults to the diff.algorithm config setting", but this is currently not the case. This fixes it, ensuring that diff.algorithm is used when -Xdiff-algorithm is not supplied. This affects the following porcelain commands: "merge", "rebase", "cherry-pick", "pull", "stash", "log", "am" and "checkout". It also affects the "merge-tree" ancillary interrogator. This change refactors the initialization of merge options to introduce two functions, "init_merge_ui_options" and "init_merge_basic_options" instead of just one "init_merge_options". This design follows the approach used in diff.c, providing initialization methods for porcelain and plumbing commands respectively. Thanks to that, the "replay" and "merge-recursive" plumbing commands remain unaffected by diff.algorithm. Signed-off-by: Antonin Delpeuch <antonin@delpeuch.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-13var(win32): do report the GIT_SHELL_PATH that is actually usedJohannes Schindelin-2/+3
On Windows, Unix-like paths like `/bin/sh` make very little sense. In the best case, they simply don't work, in the worst case they are misinterpreted as absolute paths that are relative to the drive associated with the current directory. To that end, Git does not actually use the path `/bin/sh` that is recorded e.g. when `run_command()` is called with a Unix shell command-line. Instead, as of 776297548e (Do not use SHELL_PATH from build system in prepare_shell_cmd on Windows, 2012-04-17), it re-interprets `/bin/sh` as "look up `sh` on the `PATH` and use the result instead". This is the logic users expect to be followed when running `git var GIT_SHELL_PATH`. However, when 1e65721227 (var: add support for listing the shell, 2023-06-27) introduced support for `git var GIT_SHELL_PATH`, Windows was not special-cased as above, which is why it outputs `/bin/sh` even though that disagrees with what Git actually uses. Let's fix this by using the exact same logic as `prepare_shell_cmd()`, adjusting the Windows-specific `git var GIT_SHELL_PATH` test case to verify that it actually finds a working executable. Reported-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>