aboutsummaryrefslogtreecommitdiffstats
path: root/notes-utils.c (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2021-06-14The second batchJunio C Hamano1-2/+48
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-10The first batch post Git 2.32Junio C Hamano2-1/+33
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-06Git 2.32v2.32.0Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-06parallel-checkout: avoid dash local bug in testsRené Scharfe1-1/+1
Dash bug https://bugs.launchpad.net/ubuntu/+source/dash/+bug/139097 lets the shell erroneously perform field splitting on the expansion of a command substitution during declaration of a local variable. It causes the parallel-checkout tests to fail e.g. when running them with /bin/dash on MacOS 11.4, where they error out like this: ./t2080-parallel-checkout-basics.sh: 33: local: 0: bad variable name That's because the output of wc -l contains leading spaces and the returned number of lines is treated as another variable to declare, i.e. as in "local workers= 0". Work around it by enclosing the command substitution in quotes. Helped-by: Matheus Tavares Bernardino <matheus.bernardino@usp.br> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-05l10n: es: 2.32.0 round 1Christopher Diaz Riveros1-3300/+3806
Signed-off-by: Christopher Diaz Riveros <christopher.diaz.riv@gmail.com>
2021-06-05l10n: zh_CN: for git v2.32.0 l10n round 1Jiang Xin1-3207/+3655
Translate 126 new messages (5204t0f0u) for git 2.32.0. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2021-06-05fsync(): be prepared to see EINTRJunio C Hamano1-2/+3
Some platforms, like NonStop do not automatically restart fsync() when interrupted by a signal, even when that signal is setup with SA_RESTART. This can lead to test breakage, e.g., where "--progress" is used, thus SIGALRM is sent often, and can interrupt an fsync() syscall. Make sure we deal with such a case by retrying the syscall ourselves. Luckily, we call fsync() fron a single wrapper, fsync_or_die(), so the fix is fairly isolated. Reported-by: Randall S. Becker <randall.becker@nexbridge.ca> Helped-by: Jeff King <peff@peff.net> Helped-by: Taylor Blau <me@ttaylorr.com> [jc: the above two did most of the work---I just tied the loose end] Helped-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-04l10n: Update Catalan translationJordi Mas1-4743/+5714
Signed-off-by: Jordi Mas <jmas@softcatala.org>
2021-06-02l10n: de.po: Update German translation for Git v2.32.0Matthias Rüster1-3239/+3717
Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com>
2021-06-02Git 2.32-rc3v2.32.0-rc3Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-02contrib/completion: fix zsh completion regression from 59d85a2a05David Aguilar2-2/+2
A recent change to make git-completion.bash use $__git_cmd_idx in more places broke a number of completions on zsh because it modified __git_main but did not update __git_zsh_main. Notably, completions for "add", "branch", "mv" and "push" were broken as a result of this change. In addition to the undefined variable usage, "git mv <tab>" also prints the following error: __git_count_arguments:7: bad math expression: operand expected at `"1"' _git_mv:[:7: unknown condition: -gt Remove the quotes around $__git_cmd_idx in __git_count_arguments and set __git_cmd_idx=1 early in __git_zsh_main to fix the regressions from 59d85a2a05. This was tested on zsh 5.7.1 (x86_64-apple-darwin19.0). Suggested-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: David Aguilar <davvid@gmail.com> Acked-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-02l10n: README: note on fuzzy translationsBagas Sanjaya1-0/+12
Fuzzy translation problem can occur when updating translations. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2021-06-02l10n: README: document l10n conventionsBagas Sanjaya1-0/+46
Document the conventions that l10n contributors must follow. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2021-06-02l10n: README: document "core translation"Bagas Sanjaya1-0/+24
Contributor for a new language must complete translations of a small set of l10n messages. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2021-06-02l10n: README: document git-po-helperBagas Sanjaya1-0/+31
Document the PO helper program (git-po-helper) with installation and basic usage. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2021-06-02l10n: README: add file extention ".md"Jiang Xin1-0/+0
Add file extension ".md" to "po/README" to help to display this markdown file properly. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2021-06-02builtin/fsck.c: don't conflate "int" and "enum" in callbackÆvar Arnfjörð Bjarmason1-1/+2
Fix a warning on AIX's xlc compiler that's been emitted since my a1aad71601a (fsck.h: use "enum object_type" instead of "int", 2021-03-28): "builtin/fsck.c", line 805.32: 1506-068 (W) Operation between types "int(*)(struct object*,enum object_type,void*,struct fsck_options*)" and "int(*)(struct object*,int,void*,struct fsck_options*)" is not allowed. I.e. it complains about us assigning a function with a prototype "int" where we're expecting "enum object_type". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-01l10n: pt_PT: add Portuguese translations part 3Daniel Santos1-14/+14
* Correct malformed strings * Transforming 'não' (no) into affirmative Signed-off-by: Daniel Santos <hello@brighterdan.com>
2021-05-28l10n: bg.po: Updated Bulgarian translation (5204t)Alexander Shopov1-3309/+3791
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2021-05-28Git 2.32-rc2v2.32.0-rc2Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-27dir: introduce readdir_skip_dot_and_dotdot() helperElijah Newren11-45/+30
Many places in the code were doing while ((d = readdir(dir)) != NULL) { if (is_dot_or_dotdot(d->d_name)) continue; ...process d... } Introduce a readdir_skip_dot_and_dotdot() helper to make that a one-liner: while ((d = readdir_skip_dot_and_dotdot(dir)) != NULL) { ...process d... } This helper particularly simplifies checks for empty directories. Also use this helper in read_cached_dir() so that our statistics are consistent across platforms. (In other words, read_cached_dir() should have been using is_dot_or_dotdot() and skipping such entries, but did not and left it to treat_path() to detect and mark such entries as path_none.) Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-27dir: update stale description of treat_directory()Derrick Stolee1-7/+6
The documentation comment for treat_directory() was originally written in 095952 (Teach directory traversal about subprojects, 2007-04-11) which was before the 'struct dir_struct' split its bitfield of named options into a 'flags' enum in 7c4c97c0 (Turn the flags in struct dir_struct into a single variable, 2009-02-16). When those flags changed, the comment became stale, since members like 'show_other_directories' transitioned into flags like DIR_SHOW_OTHER_DIRECTORIES. Update the comments for treat_directory() to use these flag names rather than the old member names. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-27Revert "dir: update stale description of treat_directory()"Junio C Hamano1-6/+7
This reverts commit 4e689d81718eb6e939cace317ea3e33cb994dcbb, to be replaced with a reworked version.
2021-05-27Revert "dir: introduce readdir_skip_dot_and_dotdot() helper"Junio C Hamano11-31/+45
This reverts commit b548f0f1568f6b01e55ca69c24d3cb19489f92aa, to be replaced with a reworked version.
2021-05-27pack-objects: move static inline from a header to the sole consumerÆvar Arnfjörð Bjarmason2-166/+167
Move the code that is only used in builtin/pack-objects.c out of pack-objects.h. This fixes an issue where Solaris's SunCC hasn't been able to compile git since 483fa7f42d9 (t/helper/test-bitmap.c: initial commit, 2021-03-31). The real origin of that issue is that in 898eba5e630 (pack-objects: refer to delta objects by index instead of pointer, 2018-04-14) utility functions only needed by builtin/pack-objects.c were added to pack-objects.h. Since then the header has been used in a few other places, but 483fa7f42d9 was the first time it was used by test helper. Since Solaris is stricter about linking and the oe_get_size_slow() function lives in builtin/pack-objects.c the build started failing with: Undefined first referenced symbol in file oe_get_size_slow t/helper/test-bitmap.o ld: fatal: symbol referencing errors. No output written to t/helper/test-tool On other platforms this is presumably OK because the compiler and/or linker detects that the "static inline" functions that reference oe_get_size_slow() aren't used. Let's solve this by moving the relevant code from pack-objects.h to builtin/pack-objects.c. This is almost entirely a code-only move, but because of the early macro definitions in that file referencing some of these inline functions we need to move the definition of "static struct packing_data to_pack" earlier, and declare these inline functions above the macros. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-27t2080: fix cp invocation to copy symlinks instead of following themMatheus Tavares1-1/+1
t2080 makes a few copies of a test repository and later performs a branch switch on each one of the copies to verify that parallel checkout and sequential checkout produce the same results. However, the repository is copied with `cp -R` which, on some systems, defaults to following symlinks on the directory hierarchy and copying their target files instead of copying the symlinks themselves. AIX is one example of system where this happens. Because the symlinks are not preserved, the copied repositories have paths that do not match what is in the index, causing git to abort the checkout operation that we want to test. This makes the test fail on these systems. Fix this by copying the repository with the POSIX flag '-P', which forces cp to copy the symlinks instead of following them. Note that we already use this flag for other cp invocations in our test suite (see t7001). With this change, t2080 now passes on AIX. Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-27send-email: move "hooks_path" invocation to git-send-email.perlÆvar Arnfjörð Bjarmason2-13/+2
Move the newly added "hooks_path" API in Git.pm to its only user in git-send-email.perl. This was added in c8243933c74 (git-send-email: Respect core.hooksPath setting, 2021-03-23), meaning that it hasn't yet made it into a non-rc release of git. The consensus with Git.pm is that we need to be considerate of out-of-tree users who treat it as a public documented interface. We should therefore be less willing to add new functionality to it, least we be stuck supporting it after our own uses for it disappear. In this case the git-send-email.perl hook invocation will probably be replaced by a future "git hook run" command, and in the commit preceding this one the "hooks_path" become nothing but a trivial wrapper for "rev-parse --git-path hooks" anyway (with no Cwd::abs_path() call), so let's just inline this command in git-send-email.perl itself. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-27send-email: don't needlessly abs_path() the core.hooksPathÆvar Arnfjörð Bjarmason2-5/+5
In c8243933c74 (git-send-email: Respect core.hooksPath setting, 2021-03-23) we started supporting core.hooksPath in "send-email". It's been reported that on Windows[1] doing this by calling abs_path() results in different canonicalizations of the absolute path. This wasn't an issue in c8243933c74 itself, but was revealed by my ea7811b37e0 (git-send-email: improve --validate error output, 2021-04-06) when we started emitting the path to the hook, which was previously only internal to git-send-email.perl. The just-landed 53753a37d09 (t9001-send-email.sh: fix expected absolute paths on Windows, 2021-05-24) narrowly fixed this issue, but I believe we can do better here. We should not be relying on whatever changes Perl's abs_path() makes to the path "rev-parse --git-path hooks" hands to us. Let's instead trust it, and hand it to Perl's system() in git-send-email.perl. It will handle either a relative or absolute path. So let's revert most of 53753a37d09 and just have "hooks_path" return what we get from "rev-parse" directly without modification. This has the added benefit of making the error message friendlier in the common case, we'll no longer print an absolute path for repository-local hook errors. 1. http://lore.kernel.org/git/bb30fe2b-cd75-4782-24a6-08bb002a0367@kdbg.org Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-26t1092: revert the "-1" hack for emulating "no progress meter"Junio C Hamano1-3/+3
This looked like a good idea, but it seems to break tests on 32-bit builds rather badly. Revert to just use "100 thousands must be big enough" for now. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-25l10n: id: po-id for 2.32.0 (round 1)Bagas Sanjaya1-4437/+5372
Translate following components: * builtin/add.c * worktree.c * builtin/branch.c * builtin/commit.c * builtin/merge.c * builtin/rebase.c * builtin/pull.c * diff.c * add-interactive.c * builtin/log.c * builtin/stash.c * builtin/tag.c * config.c * builtin/config.c * reset.c * builtin/remote.c * builtin/rm.c * builtin/mv.c * builtin/clean.c * builtin/help.c * archive.c * submodule.c * builtin/submodule--helper.c * submodule-config.c Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
2021-05-25t1092: use GIT_PROGRESS_DELAY for consistent resultsDerrick Stolee1-3/+3
The t1092-sparse-checkout-compatibility.sh tests compare the stdout and stderr for several Git commands across both full checkouts, sparse checkouts with a full index, and sparse checkouts with a sparse index. Since these are direct comparisons, sometimes a progress indicator can flush at unpredictable points, especially on slower machines. This causes the tests to be flaky. One standard way to avoid this is to add GIT_PROGRESS_DELAY=0 to the Git commands that are run, as this will force every progress indicator created with start_progress_delay() to be created immediately. However, there are some progress indicators that are created in the case of a full index that are not created with a sparse index. Moreover, their values may be different as those indexes have a different number of entries. Instead, use GIT_PROGRESS_DELAY=-1 (which will turn into UINT_MAX) to ensure that any reasonable machine running these tests would never display delayed progress indicators. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-25init: fix bug regarding ~/ expansion in init.templateDirMatheus Tavares2-9/+22
We used to read the init.templateDir setting at builtin/init-db.c using a git_config() callback that, in turn, called git_config_pathname(). To simplify the config reading logic at this file and plug a memory leak, this was replaced by a direct call to git_config_get_value() at e4de4502e6 ("init: remove git_init_db_config() while fixing leaks", 2021-03-14). However, this function doesn't provide path expanding semantics, like git_config_pathname() does, so paths with '~/' and '~user/' are treated literally. This makes 'git init' fail to handle init.templateDir paths using these constructs: $ git config init.templateDir '~/templates_dir' $ git init 'warning: templates not found in ~/templates_dir' Replace the git_config_get_value() call by git_config_get_pathname(), which does the '~/' and '~user/' expansions. Also add a regression test. Note that unlike git_config_get_value(), the config cache does not own the memory for the path returned by git_config_get_pathname(), so we must free() it. Reported on IRC by rkta. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-25send-email: fix missing error message regressionÆvar Arnfjörð Bjarmason2-3/+32
Fix a regression with the "the editor exited uncleanly, aborting everything" error message going missing after my d21616c0394 (git-send-email: refactor duplicate $? checks into a function, 2021-04-06). I introduced a $msg variable, but did not actually use it. This caused us to miss the optional error message supplied by the "do_edit" codepath. Fix that, and add tests to check that this works. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-25t9001-send-email.sh: fix expected absolute paths on WindowsJohannes Sixt1-4/+3
Git for Windows is a native Windows program that works with native absolute paths in the drive letter style C:\dir. The auxiliary infrastructure is based on MSYS2, which uses POSIX style /C/dir. When we test for output of absolute paths produced by git.exe, we usally have to expect C:\dir style paths. To produce such expected paths, we have to use $(pwd) in the test scripts; the alternative, $PWD, produces a POSIX style path. ($PWD is a shell variable, and the shell is bash, an MSYS2 program, and operates in the POSIX realm.) There are two recently added tests that were written to expect C:\dir paths. The output that is tested is produced by `git send-email`, but behind the scenes, this is a Perl script, which also works in the POSIX realm and produces /C/dir style output. In the first test case that is changed here, replace $(pwd) by $PWD so that the expected path is constructed using /C/dir style. The second test case sets core.hooksPath to an absolute path. Since the test script talks to native git.exe, it is supposed to place a C:/dir style path into the configuration; therefore, keep $(pwd). When this configuration value is consumed by the Perl script, it is transformed to /C/dir style by the MSYS2 layer and echoed back in this form in the error message. Hence, do use $PWD for the expected value. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-25packfile-uri.txt: fix blobPackfileUri descriptionTeng Long1-7/+8
Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt and the correct format also can be seen in t5702. Signed-off-by: Teng Long <dyroneteng@gmail.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-24doc: avoid using rm directlyFelipe Contreras1-3/+3
That's what we have $(RM) for. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-24doc: simplify Makefile using .DELETE_ON_ERRORFelipe Contreras1-28/+19
Currently GNU make already removes files when catching an interruption signal, however, in order to deal with other kinds of errors a workaround is in place to store target output to a temporary file, and only move it to its right place on success. By enabling the built-in .DELETE_ON_ERROR we let make do this task, so we don't have to. This way the rules can be simplified a lot. Suggested-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-24doc: remove unnecessary rm instancesFelipe Contreras1-27/+15
Commits 50cff52f1a (When generating manpages, delete outdated targets first., 2007-08-02) and f9286765b2 (Documentation/Makefile: remove cmd-list.made before redirecting to it., 2007-08-06) created these rm instances for a very rare corner-case: building as root by mistake. It's odd to have workarounds here, but nowhere else in the Makefile-- which already fails in this stuation, starting from Documentation/technical/. We gain nothing but complexity, so let's remove them. Comments-by: Jeff King <peff@peff.net> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-24doc: improve asciidoc dependenciesFelipe Contreras1-1/+2
asciidoc needs asciidoc.conf, asciidoctor asciidoctor-extensions.rb. Neither needs the other. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-24doc: refactor common asciidoc dependenciesFelipe Contreras1-3/+4
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-24l10n: vi.po(5204t): Updated Vietnamese translation for v2.32.0Tran Ngoc Quan1-3196/+3691
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2021-05-23l10n: zh_TW.po: localizedYi-Jyun Pan1-82/+82
Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>
2021-05-22Git 2.32-rc1v2.32.0-rc1Junio C Hamano2-1/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-22t: use configured TAR instead of tarĐoàn Trần Công Danh2-4/+4
Despite that tar is available everywhere, it's not required by POSIX. In our build system, users are allowed to specify which tar to be used in Makefile knobs. Furthermore, GNU tar (gtar) is prefered when autotools is being used. In our testsuite, 7 out of 9 tar-required-tests use "$TAR", the other two use "tar". Let's change the remaining two tests to "$TAR". Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-22stash show: use stash.showIncludeUntracked even when diff options givenDenton Liu4-9/+10
If options pertaining to how the diff is displayed is provided to `git stash show`, the command will ignore the stash.showIncludeUntracked configuration variable, defaulting to not showing any untracked files. This is unintuitive behaviour since the format of the diff output and whether or not to display untracked files are orthogonal. Use stash.showIncludeUntracked even when diff options are given. Of course, this is still overridable via the command-line options. Update the documentation to explicitly say which configuration variables will be overridden when a diff options are given. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-21l10n: zh_TW.po: v2.32.0 round 1 (11 untranslated)Yi-Jyun Pan1-3230/+3714
Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>
2021-05-21diff-merges: let "-m" imply "-p"Sergey Organov3-6/+7
Fix long standing inconsistency between -c/--cc that do imply -p on one side, and -m that did not imply -p on the other side. Change corresponding test accordingly, as "log -m" output should now match one from "log -m -p", rather than from just "log". Change documentation accordingly. NOTES: After this patch git log -m produces diffs without need to provide -p as well, that improves both consistency and usability. It gets even more useful if one sets "log.diffMerges" configuration variable to "first-parent" to force -m produce usual diff with respect to first parent only. This patch, however, does not change behavior when specific diff format is explicitly provided on the command-line, so that commands like git log -m --raw git log -m --stat are not affected, nor does it change commands where specific diff format is active by default, such as: git diff-tree -m It's also worth to be noticed that exact historical semantics of -m is still provided by --diff-merges=separate. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-21diff-merges: rename "combined_imply_patch" to "merges_imply_patch"Sergey Organov2-6/+6
This is refactoring change in preparation for the next commit that will let -m imply -p. The old name doesn't match the intention to let not only -c/-cc imply -p, but also -m, that is not a "combined" format, so we rename the flag accordingly. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-21stash list: stop passing "-m" to "git log"Sergey Organov2-2/+2
Passing "-m" in "git log --first-parent -m" is not needed as --first-parent implies --diff-merges=first-parent anyway. OTOH, it will stop being harmless once we let "-m" imply "-p". While we are at it, fix corresponding test description in t3903-stash to match what it actually tests. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-21git-svn: stop passing "-m" to "git rev-list"Sergey Organov1-1/+1
rev-list doesn't utilize -m. It happens to eat it silently, so this bug went unnoticed. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>