summaryrefslogtreecommitdiffstats
path: root/sideband.h (unfollow)
Commit message (Collapse)AuthorFilesLines
2022-04-28Some regression fixes for 2.36Junio C Hamano3-2/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-26submodule--helper: fix initialization of warn_if_uninitializedOrgad Shaneh2-1/+33
The .warn_if_uninitialized member was introduced by 48308681 (git submodule update: have a dedicated helper for cloning, 2016-02-29) to submodule_update_clone struct and initialized to false. When c9911c93 (submodule--helper: teach update_data more options, 2022-03-15) moved it to update_data struct, it started to initialize it to true but this change was not explained in its log message. The member is set to true only when pathspec was given, and is used when a submodule that matched the pathspec is found uninitialized to give diagnostic message. "submodule update" without pathspec is supposed to iterate over all submodules (i.e. without pathspec limitation) and update only the initialized submodules, and finding uninitialized submodules during the iteration is a totally expected and normal thing that should not be warned. [jc: added tests] Signed-off-by: Orgad Shaneh <orgads@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-262.36 gitk/diff-tree --stdin regression fixJunio C Hamano3-0/+18
This only surfaced as a regression after 2.36 release, but the breakage was already there with us for at least a year. The diff_free() call is to be used after we completely finished with a diffopt structure. After "git diff A B" finishes producing output, calling it before process exit is fine. But there are commands that prepares diff_options struct once, compares two sets of paths, releases resources that were used to do the comparison, then reuses the same diff_option struct to go on to compare the next two sets of paths, like "git log -p". After "git log -p" finishes showing a single commit, calling it before it goes on to the next commit is NOT fine. There is a mechanism, the .no_free member in diff_options struct, to help "git log" to avoid calling diff_free() after showing each commit and instead call it just one. When the mechanism was introduced in e900d494 (diff: add an API for deferred freeing, 2021-02-11), however, we forgot to do the same to "diff-tree --stdin", which *is* a moral equivalent to "git log". During 2.36 release cycle, we started clearing the pathspec in diff_free(), so programs like gitk that runs git diff-tree --stdin -- <pathspec> downstream of a pipe, processing one commit after another, started showing irrelevant comparison outside the given <pathspec> from the second commit. The same commit, by forgetting to teach the .no_free mechanism, broke "diff-tree --stdin -I<regexp>" and nobody noticed it for over a year, presumably because it is so seldom used an option. But <pathspec> is a different story. The breakage was very prominently visible and was reported immediately after 2.36 was released. Fix this breakage by mimicking how "git log" utilizes the .no_free member so that "diff-tree --stdin" behaves more similarly to "log". Protect the fix with a few new tests. Reported-by: Matthias Aßhauer <mha1993@live.de> Helped-by: René Scharfe <l.s.r@web.de> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-23Revert "name-rev: release unused name strings"René Scharfe1-16/+5
This reverts commit 2d53975488df195e1431c3f90bfb5b60018d5bf6. 3656f84278 (name-rev: prefer shorter names over following merges, 2021-12-04) broke the assumption of 2d53975488 (name-rev: release unused name strings, 2020-02-04) that a better name for a child is a better name for all of its ancestors as well, because it added a penalty for generation > 0. This leads to strings being free(3)'d that are still needed. 079f970971 (name-rev: sort tip names before applying, 2020-02-05) already reduced the number of free(3) calls for the use case that motivated the original patch (name-rev --all in the Chromium repository) from ca. 44000 to 5, and 3656f84278 eliminated even those few. So this revert won't affect name-rev's performance on that particular repo. Reported-by: Thomas Hurst <tom@hur.st> Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-18Git 2.36v2.36.0Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-17l10n: sv.po: Update Swedish translation (5282t0f0u)Peter Krefting1-3959/+4735
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2022-04-16l10n: Update Catalan translationJordi Mas1-4044/+4892
Signed-off-by: Jordi Mas <jmas@softcatala.org>
2022-04-16l10n: po-id for 2.36 (round 2)Bagas Sanjaya1-287/+121
Translate following new components: * setup.c * split-index.c * strbuf.c * trailer.c Also delete obsolete strings. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2022-04-16config.mak.dev: alternative workaround to gcc 12 warning in http.cCarlo Marcelo Arenas Belón1-0/+1
This provides a "no code change needed" option to the "fix" currently queued as part of ab/http-gcc-12-workaround and therefore should be reverted once that gets merged. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-16config.mak.dev: workaround gcc 12 bug affecting "pedantic" CI jobCarlo Marcelo Arenas Belón1-0/+5
Originally noticed by Peff[1], but yet to be corrected[2] and planned to be released with Fedora 36 (scheduled for Apr 19). dir.c: In function ‘git_url_basename’: dir.c:3085:13: error: ‘memchr’ specified bound [9223372036854775808, 0] exceeds maximum object size 9223372036854775807 [-Werror=stringop-overread] 3085 | if (memchr(start, '/', end - start) == NULL | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fedora is used as part of the CI, and therefore that release will trigger failures, unless the version of the image used is locked to an older release, as an alternative. Restricting the flag to the affected source file, as well as implementing an independent facility to track these workarounds was specifically punted to minimize the risk of introducing problems so close to a release. This change should be reverted once the underlying gcc bug is solved and which should be visible by NOT triggering a warning, otherwise. [1] https://lore.kernel.org/git/YZQhLh2BU5Hquhpo@coredump.intra.peff.net/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=2075786 Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-14l10n: de.po: Update German translationMatthias Rüster1-4024/+4576
Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com> Reviewed-by: Phillip Szelat <phillip.szelat@gmail.com> Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com>
2022-04-14l10n: zh_CN v2.36.0 round 2Fangyi Zhou1-307/+65
Signed-off-by: Fangyi Zhou <me@fangyi.io>
2022-04-14l10n: pt_PT: update Portuguese translationDaniel Santos1-6428/+7063
* update the following words translations: commit, untracked, stage, cache, stash, work..., index, reset, label, check..., tags, graft, alternate object, amend, ancestor, cherry-pick, bisect, blame, chain, cache, bug, chunk, branch, bundle, clean, clone, commit-graph, commit object, commit-ish, committer, cover letter, conflict, dangling, detach, dir, dumb, fast-forward, file system, fixup, fork, fetch, Git archive, gitdir, graft, replace ref * correct some mispellings * git-po-helper update * remove some obsolete lines * unfuzzy entries * random translation updates * update contact in pt_PT.po * add the following words to the translation table: override, recurse, print, offset, unbundle, mirror repository, multi-pack, bad, whitespace, batch * remove the following words of the translation table: core Git * change the following words on the translation table: dry-run, apply, patch, replay, blame, chain, gitdir, file system, fork, unset, handle * some translation to the first person * update copyright text * word 'utilização:' to 'uso:' * word 'pai' to 'parente' Signed-off-by: Daniel Santos <dacs.git@brilhante.top>
2022-04-14l10n: vi(5285t): v2.36.0 round 2Tran Ngoc Quan1-3937/+4752
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2022-04-14l10n: zh_TW: v2.36.0 round 2Yi-Jyun Pan1-3973/+4749
Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>
2022-04-14RelNotes: revert the description on the reverted topicsJunio C Hamano1-10/+0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-14RelNotes: mention safe.directoryJunio C Hamano1-2/+9
Helped-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-14RelNotes: clarify "bisect run unexecutable" tweakJunio C Hamano1-4/+4
We do not have to guess how common the mistake the change targets is when describing it. Such an argument may be good while proposing a change, but does not quite belong in the record of what has already happened, i.e. a release note. Helped-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-14Revert "fetch: increase test coverage of fetches"Junio C Hamano2-93/+0
This reverts commit 2a0cafd464709cfa22fe7249290c644a2a26c520, as it expects a working "a ref deletion must produce a single transaction, not one for loose and another for packed" topic, which we do not have.
2022-04-14Revert "Merge branch 'ps/avoid-unnecessary-hook-invocation-with-packed-refs'"Junio C Hamano8-114/+19
This reverts commit 991b4d47f0accd3955d05927d5ce434e03ffbdb6, reversing changes made to bcd020f88e1e22f38422ac3f73ab06b34ec4bef1.
2022-04-13Git 2.30.4v2.30.4Junio C Hamano3-2/+23
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13setup: opt-out of check with safe.directory=*Derrick Stolee3-2/+21
With the addition of the safe.directory in 8959555ce (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02) released in v2.35.2, we are receiving feedback from a variety of users about the feature. Some users have a very large list of shared repositories and find it cumbersome to add this config for every one of them. In a more difficult case, certain workflows involve running Git commands within containers. The container boundary prevents any global or system config from communicating `safe.directory` values from the host into the container. Further, the container almost always runs as a different user than the owner of the directory in the host. To simplify the reactions necessary for these users, extend the definition of the safe.directory config value to include a possible '*' value. This value implies that all directories are safe, providing a single setting to opt-out of this protection. Note that an empty assignment of safe.directory clears all previous values, and this is already the case with the "if (!value || !*value)" condition. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13setup: fix safe.directory key not being checkedMatheus Valadares2-0/+8
It seems that nothing is ever checking to make sure the safe directories in the configs actually have the key safe.directory, so some unrelated config that has a value with a certain directory would also make it a safe directory. Signed-off-by: Matheus Valadares <me@m28.io> Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13t0033: add tests for safe.directoryDerrick Stolee2-1/+36
It is difficult to change the ownership on a directory in our test suite, so insert a new GIT_TEST_ASSUME_DIFFERENT_OWNER environment variable to trick Git into thinking we are in a differently-owned directory. This allows us to test that the config is parsed correctly. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-13l10n: fr: v2.36 round 2Jean-Noël Avila1-89/+165
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2022-04-13l10n: tr: v2.36.0 round 2Emir SARI1-62/+84
Signed-off-by: Emir SARI <emir_sari@icloud.com>
2022-04-13l10n: git.pot: v2.36.0 round 2 (4 new, 3 removed)Jiang Xin1-40/+52
Generate po/git.pot from v2.36.0-rc2 for git v2.36.0 l10n round 2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2022-04-12Git 2.36-rc2v2.36.0-rc2Junio C Hamano2-1/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-11i18n: fix some badly formatted i18n stringsJean-Noël Avila2-5/+4
String in submodule--helper is not correctly formatting placeholders. The string in git-send-email is partial. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-09l10n: fr: v2.36 round 1Jean-Noël Avila1-3969/+4717
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2022-04-08Git 2.36-rc1v2.36.0-rc1Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-08t9902: split test to run on appropriate systemsAdam Dinwoodie1-9/+26
The "FUNNYNAMES" test prerequisite passes on Cygwin, as the Cygwin file system interface has a workaround for the underlying operating system's lack of support for tabs, newlines or quotes. However, it does not add support for backslash, which is treated as a directory separator, meaning one of the tests added by 48803821b1 ("completion: handle unusual characters for sparse-checkout", 2022-02-07) will fail on Cygwin. To avoid this failure while still getting maximal test coverage, split that test into two: test handling of paths that include tabs on anything that has the FUNNYNAMES prerequisite, but skip testing handling of paths that include backslashes unless both FUNNYNAMES is set and the system is not Cygwin. It might be nice to have more granularity than "FUNNYNAMES" and its sibling "FUNNIERNAMES" provide, so that tests could be run based on specific individual characters supported by the file system being tested, but that seems like it would make the prerequisite checks in this area much more verbose for very little gain. Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-08ls-tree doc: document interaction with submodulesÆvar Arnfjörð Bjarmason1-2/+2
The ls-tree documentation had never been updated after it learned to interact with submodules to explicitly mention them. The initial support was added in f35a6d3bce7 (Teach core object handling functions about gitlinks, 2007-04-09). E.g. the discussion of --long added in f35a6d3bce7 (Teach core object handling functions about gitlinks, 2007-04-09) didn't explicitly mention them. But this documentation added in 455923e0a15 (ls-tree: introduce "--format" option, 2022-03-23) had no such excuse, and was actively misleading by providing an exhaustive but incomplete list of object types we'd emit. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-08l10n: zh_CN v2.36.0 round 1Fangyi Zhou1-3935/+4704
Reviewed-by: 依云 <lilydjwg@gmail.com> Signed-off-by: Fangyi Zhou <me@fangyi.io>
2022-04-08l10n: Update zh_CN repo linkFangyi Zhou2-2/+2
Signed-off-by: Fangyi Zhou <me@fangyi.io>
2022-04-07Documentation: add --batch-command to cat-file synopsisÆvar Arnfjörð Bjarmason1-1/+1
440c705ea63 (cat-file: add --batch-command mode, 2022-02-18) added the new option and operating mode without listing it to the synopsis section. Fix it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-07git-ls-tree.txt: fix the name of "%(objectsize:padded)"Martin Ågren1-1/+1
Commit 455923e0a1 ("ls-tree: introduce "--format" option", 2022-03-23) introduced `--format` and the various placeholders it can take, such as %(objectname) and %(objectsize). At some point when that patch was being developed, those placeholders had shorter names, e.g., %(name) and %(size), which can be seen in the commit message of 455923e0a1. One instance of "%(size:padded)" also managed to enter the documentation in the final version of the patch. Correct it to "%(objectsize:padded)". Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-07submodule-helper: fix usage stringFangyi Zhou1-1/+1
The missing space at the end of the line makes the closing square bracket sticking to the dash in the next line Found during localisation v2.36.0 round 1 Signed-off-by: Fangyi Zhou <me@fangyi.io> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-07l10n: po-id for 2.36 (round 1)Bagas Sanjaya1-4206/+5075
Update following components: * add-interactive.c * branch.c * config.c * help.c * merge-ort-wrappers.c * builtin/bisect--helper.c * builtin/branch.c * builtin/cat-file.c * builtin/checkout.c * builtin/clone.c * builtin/config.c * builtin/reflog.c * builtin/remote.c * builtin/sparse-checkout.c * builtin/submodule--helper.c * builtin/unpack-objects.c Translate following new components: * connect.c * connected.c * date.c * hook.c * files-backend.c * ident.c * merge-ort.c * merge-recursive.c * refs.c * refspec.c * revision.c * symlinks.c * worktree.c * builtin/notes.c * builtin/multi-pack-index.c * builtin/commit.c * builtin/merge-base.c Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
2022-04-07doc: replace "--" with {litdd} in credential-cache/fsmonitorTodd Zullinger4-11/+11
Asciidoc renders `--` as em-dash. This is not appropriate for command names. It also breaks linkgit links to these commands. Fix git-credential-cache--daemon and git-fsmonitor--daemon. The latter was added 3248486920 (fsmonitor: document builtin fsmonitor, 2022-03-25) and included several links. A check for broken links in the HTML docs turned this up. Manually inspecting the other Documentation/git-*--*.txt files turned up the issue in git-credential-cache--daemon. While here, quote `git credential-cache--daemon` in the synopsis to match the vast majority of our other documentation. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-06contrib/scalar: fix 'all' target in MakefileVictoria Dye1-1/+1
Add extra ':' to second 'all' target definition to allow 'scalar' to build. Without this fix, the 'all:' and 'all::' targets together cause a build failure when 'scalar' build is enabled with 'INCLUDE_SCALAR': Makefile:14: *** target file `all' has both : and :: entries. Stop. Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-06Documentation/Makefile: fix "make info" regression in dad9cd7d518Ævar Arnfjörð Bjarmason1-1/+1
Fix a regression in my dad9cd7d518 (Makefile: move ".SUFFIXES" rule to shared.mak, 2022-03-03). As explained in the GNU make documentation for the $* variable, available at: info make --index-search='$*' This rule relied on ".texi" being in the default list of suffixes, as seen at: make -f/dev/null -p | grep -v -e ^# -e ^$|grep -F .SUFFIXES The documentation explains what was going on here: In an explicit rule, there is no stem; so '$*' cannot be determined in that way. Instead, if the target name ends with a recognized suffix (*note Old-Fashioned Suffix Rules: Suffix Rules.), '$*' is set to the target name minus the suffix. For example, if the target name is 'foo.c', then '$*' is set to 'foo', since '.c' is a suffix. GNU 'make' does this bizarre thing only for compatibility with other implementations of 'make'. You should generally avoid using '$*' except in implicit rules or static pattern rules. If the target name in an explicit rule does not end with a recognized suffix, '$*' is set to the empty string for that rule. I.e. this rule added back in 5cefc33bffd (Documentation: add gitman.info target, 2007-12-10) was resolving gitman.texi from gitman.info. We can instead just use the more obvious $< variable referring to the prerequisite. This was the only use of $* in our Makefiles in an explicit rule, the three remaining ones are all implicit rules, and therefore didn't depend on the ".SUFFIXES" list. Reported-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Tested-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-06configure.ac: fix HAVE_SYNC_FILE_RANGE definitionAdam Dinwoodie1-1/+1
If sync_file_range is not available when building the configure script, there is a cosmetic bug when running that script reporting "HAVE_SYNC_FILE_RANGE: command not found". Remove that error message by defining HAVE_SYNC_FILE_RANGE to an empty string, rather than generating a script where that appears as a bare command. Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-06git-compat-util: really support openssl as a source of entropyCarlo Marcelo Arenas Belón3-1/+6
05cd988dce5 (wrapper: add a helper to generate numbers from a CSPRNG, 2022-01-17), configure openssl as the source for entropy in NON-STOP but doesn't add the needed header or link options. Since the only system that is configured to use openssl as a source of entropy is NON-STOP, add the header unconditionally, and -lcrypto to the list of external libraries. An additional change is required to make sure a NO_OPENSSL=1 build will be able to work as well (tested on Linux with a modified value of CSPRNG_METHOD = openssl), and the more complex logic that allows for compatibility with APPLE_COMMON_CRYPTO or allowing for simpler ways to link (without libssl) has been punted for now. Reported-by: Randall Becker <rsbecker@nexbridge.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-06ls-tree: `-l` should not imply recursive listingJosh Steadmon1-1/+1
In 9c4d58ff2c (ls-tree: split up "fast path" callbacks, 2022-03-23), a refactoring of the various read_tree_at() callbacks caused us to unconditionally recurse into directories if `-l` (long format) was passed on the command line, regardless of whether or not we also pass the `-r` (recursive) flag. Fix this by making show_tree_long() return the value of `recurse`, rather than always returning 1. This value is interpreted by read_tree_at() to be a signal on whether or not to recurse. Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-06l10n: tr: v2.36.0 round 1Emir SARI1-3958/+4479
Signed-off-by: Emir SARI <emir_sari@icloud.com>
2022-04-06l10n: git.pot: v2.36.0 round 1 (192 new, 106 removed)Jiang Xin1-3828/+4320
Generate po/git.pot from v2.36.0-rc0 for git v2.36.0 l10n round 1. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2022-04-04Git 2.36-rc0v2.36.0-rc0Junio C Hamano2-1/+33
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-01tracking branches: add advice to ambiguous refspec errorTao Klerks5-9/+78
The error "not tracking: ambiguous information for ref" is raised when we are evaluating what tracking information to set on a branch, and find that the ref to be added as tracking branch is mapped under multiple remotes' fetch refspecs. This can easily happen when a user copy-pastes a remote definition in their git config, and forgets to change the tracking path. Add advice in this situation, explicitly highlighting which remotes are involved and suggesting how to correct the situation. Also update a test to explicitly expect that advice. Signed-off-by: Tao Klerks <tao@klerks.biz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-04-01branch.c: simplify advice-and-die sequenceGlen Choo1-7/+4
In the dwim_branch_start(), when we cannot find an appropriate upstream, we will die with the same message anyway, whether we issue an advice message. Flip the code around a bit and simplify the flow using advise_if_enabled() function. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Glen Choo <chooglen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>