Skip to main content

Browse the archive

https://github.com/git/git
05 April 2024, 19:32:26 UTC
sort by:
Revision Author Date Message Commit Date
fd59c5b Johannes Schindelin 23 June 2022, 10:36:14 UTC Git 2.36.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:40:44 UTC
8f8eea8 Johannes Schindelin 23 June 2022, 10:36:12 UTC Sync with 2.35.4 * maint-2.35: Git 2.35.4 Git 2.34.4 Git 2.33.4 Git 2.32.3 Git 2.31.4 Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo 23 June 2022, 10:36:12 UTC
359da65 Johannes Schindelin 23 June 2022, 10:36:05 UTC Git 2.35.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:36:05 UTC
aef3d59 Johannes Schindelin 23 June 2022, 10:36:03 UTC Sync with 2.34.4 * maint-2.34: Git 2.34.4 Git 2.33.4 Git 2.32.3 Git 2.31.4 Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo 23 June 2022, 10:36:03 UTC
f2eed22 Johannes Schindelin 23 June 2022, 10:35:49 UTC Git 2.34.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:35:49 UTC
378eade Johannes Schindelin 23 June 2022, 10:35:47 UTC Sync with 2.33.4 * maint-2.33: Git 2.33.4 Git 2.32.3 Git 2.31.4 Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo 23 June 2022, 10:35:47 UTC
80c525c Johannes Schindelin 23 June 2022, 10:35:41 UTC Git 2.33.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:35:41 UTC
eebfde3 Johannes Schindelin 23 June 2022, 10:35:38 UTC Sync with 2.32.3 * maint-2.32: Git 2.32.3 Git 2.31.4 Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo 23 June 2022, 10:35:38 UTC
656d9a2 Johannes Schindelin 23 June 2022, 10:35:32 UTC Git 2.32.3 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:35:32 UTC
fc0c773 Johannes Schindelin 23 June 2022, 10:35:30 UTC Sync with 2.31.4 * maint-2.31: Git 2.31.4 Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo 23 June 2022, 10:35:30 UTC
5b1c746 Johannes Schindelin 23 June 2022, 10:35:25 UTC Git 2.31.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:35:25 UTC
2f8809f Johannes Schindelin 23 June 2022, 10:35:23 UTC Sync with 2.30.5 * maint-2.30: Git 2.30.5 setup: tighten ownership checks post CVE-2022-24765 git-compat-util: allow root to access both SUDO_UID and root owned t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo 23 June 2022, 10:35:23 UTC
88b7be6 Johannes Schindelin 27 May 2022, 21:38:36 UTC Git 2.30.5 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:31:05 UTC
3b0bf27 Carlo Marcelo Arenas Belón 10 May 2022, 19:35:29 UTC setup: tighten ownership checks post CVE-2022-24765 8959555cee7 (setup_git_directory(): add an owner check for the top-level directory, 2022-03-02), adds a function to check for ownership of repositories using a directory that is representative of it, and ways to add exempt a specific repository from said check if needed, but that check didn't account for owership of the gitdir, or (when used) the gitfile that points to that gitdir. An attacker could create a git repository in a directory that they can write into but that is owned by the victim to work around the fix that was introduced with CVE-2022-24765 to potentially run code as the victim. An example that could result in privilege escalation to root in *NIX would be to set a repository in a shared tmp directory by doing (for example): $ git -C /tmp init To avoid that, extend the ensure_valid_ownership function to be able to check for all three paths. This will have the side effect of tripling the number of stat() calls when a repository is detected, but the effect is expected to be likely minimal, as it is done only once during the directory walk in which Git looks for a repository. Additionally make sure to resolve the gitfile (if one was used) to find the relevant gitdir for checking. While at it change the message printed on failure so it is clear we are referring to the repository by its worktree (or gitdir if it is bare) and not to a specific directory. Helped-by: Junio C Hamano <junio@pobox.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> 23 June 2022, 10:31:05 UTC
b779214 Junio C Hamano 26 May 2022, 21:51:32 UTC Merge branch 'cb/path-owner-check-with-sudo' With a recent update to refuse access to repositories of other people by default, "sudo make install" and "sudo git describe" stopped working. This series intends to loosen it while keeping the safety. * cb/path-owner-check-with-sudo: t0034: add negative tests and allow git init to mostly work under sudo git-compat-util: avoid failing dir ownership checks if running privileged t: regression git needs safe.directory when using sudo Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 23 June 2022, 10:31:04 UTC
6b11e3d Carlo Marcelo Arenas Belón 17 June 2022, 20:23:38 UTC git-compat-util: allow root to access both SUDO_UID and root owned Previous changes introduced a regression which will prevent root for accessing repositories owned by thyself if using sudo because SUDO_UID takes precedence. Loosen that restriction by allowing root to access repositories owned by both uid by default and without having to add a safe.directory exception. A previous workaround that was documented in the tests is no longer needed so it has been removed together with its specially crafted prerequisite. Helped-by: Johanness Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2022, 21:03:08 UTC
dc8c8de Junio C Hamano 08 June 2022, 01:48:52 UTC Prepare for 2.36.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 June 2022, 21:27:53 UTC
d2b11e0 Junio C Hamano 08 June 2022, 21:27:53 UTC Merge branch 'jc/clone-remote-name-leak-fix' into maint "git clone --origin X" leaked piece of memory that held value read from the clone.defaultRemoteName configuration variable, which has been plugged. source: <xmqqlevl4ysk.fsf@gitster.g> * jc/clone-remote-name-leak-fix: clone: plug a miniscule leak 08 June 2022, 21:27:53 UTC
67c305f Junio C Hamano 08 June 2022, 21:27:53 UTC Merge branch 'ds/midx-normalize-pathname-before-comparison' into maint The path taken by "git multi-pack-index" command from the end user was compared with path internally prepared by the tool withut first normalizing, which lead to duplicated paths not being noticed, which has been corrected. source: <pull.1221.v2.git.1650911234.gitgitgadget@gmail.com> * ds/midx-normalize-pathname-before-comparison: cache: use const char * for get_object_directory() multi-pack-index: use --object-dir real path midx: use real paths in lookup_multi_pack_index() 08 June 2022, 21:27:53 UTC
363d54f Junio C Hamano 08 June 2022, 21:27:52 UTC Merge branch 'ah/rebase-keep-base-fix' into maint "git rebase --keep-base <upstream> <branch-to-rebase>" computed the commit to rebase onto incorrectly, which has been corrected. source: <20220421044233.894255-1-alexhenrie24@gmail.com> * ah/rebase-keep-base-fix: rebase: use correct base for --keep-base when a branch is given 08 June 2022, 21:27:52 UTC
d777ef9 Junio C Hamano 08 June 2022, 21:27:52 UTC Merge branch 'pw/test-malloc-with-sanitize-address' into maint Avoid problems from interaction between malloc_check and address sanitizer. source: <pull.1210.git.1649507317350.gitgitgadget@gmail.com> * pw/test-malloc-with-sanitize-address: tests: make SANITIZE=address imply TEST_NO_MALLOC_CHECK 08 June 2022, 21:27:52 UTC
ac8f6b6 Junio C Hamano 08 June 2022, 21:27:52 UTC Merge branch 'rs/commit-summary-wo-break-rewrite' into maint The commit summary shown after making a commit is matched to what is given in "git status" not to use the break-rewrite heuristics. source: <c35bd0aa-2e46-e710-2b39-89f18bad0097@web.de> * rs/commit-summary-wo-break-rewrite: commit, sequencer: turn off break_opt for commit summary 08 June 2022, 21:27:52 UTC
a5a5273 Junio C Hamano 08 June 2022, 21:27:52 UTC Merge branch 'mg/detect-compiler-in-c-locale' into maint Build procedure fixup. source: <f306f43f375bc9b9c98e85260587442e5d9ef0ba.1652094958.git.git@grubix.eu> * mg/detect-compiler-in-c-locale: detect-compiler: make detection independent of locale 08 June 2022, 21:27:52 UTC
080b062 Junio C Hamano 08 June 2022, 21:27:51 UTC Merge branch 'cb/ci-make-p4-optional' into maint macOS CI jobs have been occasionally flaky due to tentative version skew between perforce and the homebrew packager. Instead of failing the whole CI job, just let it skip the p4 tests when this happens. source: <20220512223940.238367-1-gitster@pobox.com> * cb/ci-make-p4-optional: ci: use https, not http to download binaries from perforce.com ci: reintroduce prevention from perforce being quarantined in macOS ci: avoid brew for installing perforce ci: make failure to find perforce more user friendly 08 June 2022, 21:27:51 UTC
f02e234 Junio C Hamano 08 June 2022, 21:27:51 UTC Merge branch 'ab/valgrind-fixes' into maint A bit of test framework fixes with a few fixes to issues found by valgrind. source: <20220512223218.237544-1-gitster@pobox.com> * ab/valgrind-fixes: commit-graph.c: don't assume that stat() succeeds object-file: fix a unpack_loose_header() regression in 3b6a8db3b03 log test: skip a failing mkstemp() test under valgrind tests: using custom GIT_EXEC_PATH breaks --valgrind tests 08 June 2022, 21:27:51 UTC
9d13041 Junio C Hamano 08 June 2022, 21:27:51 UTC Merge branch 'jc/archive-add-file-normalize-mode' into maint "git archive --add-file=<path>" picked up the raw permission bits from the path and propagated to zip output in some cases, without normalization, which has been corrected (tar output did not have this issue). source: <xmqqmtfme8v6.fsf@gitster.g> * jc/archive-add-file-normalize-mode: archive: do not let on-disk mode leak to zip archives 08 June 2022, 21:27:51 UTC
c47b89c Junio C Hamano 08 June 2022, 21:27:51 UTC Merge branch 'jc/show-branch-g-current' into maint The "--current" option of "git show-branch" should have been made incompatible with the "--reflog" mode, but this was not enforced, which has been corrected. source: <xmqqh76mf7s4.fsf_-_@gitster.g> * jc/show-branch-g-current: show-branch: -g and --current are incompatible 08 June 2022, 21:27:51 UTC
b8117d2 Junio C Hamano 08 June 2022, 21:27:50 UTC Merge branch 'jc/update-ozlabs-url' into maint Update URL to the gitk repository. * jc/update-ozlabs-url: SubmittingPatches: use more stable git.ozlabs.org URL 08 June 2022, 21:27:51 UTC
79d1e6d Junio C Hamano 08 June 2022, 21:27:50 UTC Merge branch 'jc/http-clear-finished-pointer' into maint Meant to go with js/ci-gcc-12-fixes. source: <xmqq7d68ytj8.fsf_-_@gitster.g> * jc/http-clear-finished-pointer: http.c: clear the 'finished' member once we are done with it 08 June 2022, 21:27:50 UTC
596838d Junio C Hamano 08 June 2022, 21:27:50 UTC Merge branch 'js/ci-gcc-12-fixes' into maint Fixes real problems noticed by gcc 12 and works around false positives. source: <pull.1238.git.1653351786.gitgitgadget@gmail.com> * js/ci-gcc-12-fixes: dir.c: avoid "exceeds maximum object size" error with GCC v12.x nedmalloc: avoid new compile error compat/win32/syslog: fix use-after-realloc 08 June 2022, 21:27:50 UTC
05e280c Junio C Hamano 26 May 2022, 19:37:31 UTC http.c: clear the 'finished' member once we are done with it In http.c, the run_active_slot() function allows the given "slot" to make progress by calling step_active_slots() in a loop repeatedly, and the loop is not left until the request held in the slot completes. Ages ago, we used to use the slot->in_use member to get out of the loop, which misbehaved when the request in "slot" completes (at which time, the result of the request is copied away from the slot, and the in_use member is cleared, making the slot ready to be reused), and the "slot" gets reused to service a different request (at which time, the "slot" becomes in_use again, even though it is for a different request). The loop terminating condition mistakenly thought that the original request has yet to be completed. Today's code, after baa7b67d (HTTP slot reuse fixes, 2006-03-10) fixed this issue, uses a separate "slot->finished" member that is set in run_active_slot() to point to an on-stack variable, and the code that completes the request in finish_active_slot() clears the on-stack variable via the pointer to signal that the particular request held by the slot has completed. It also clears the in_use member (as before that fix), so that the slot itself can safely be reused for an unrelated request. One thing that is not quite clean in this arrangement is that, unless the slot gets reused, at which point the finished member is reset to NULL, the member keeps the value of &finished, which becomes a dangling pointer into the stack when run_active_slot() returns. Clear the finished member before the control leaves the function, which has a side effect of unconfusing compilers like recent GCC 12 that is over-eager to warn against such an assignment. Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 May 2022, 22:58:31 UTC
2acf4cf Johannes Schindelin 24 May 2022, 00:23:06 UTC dir.c: avoid "exceeds maximum object size" error with GCC v12.x Technically, the pointer difference `end - start` _could_ be negative, and when cast to an (unsigned) `size_t` that would cause problems. In this instance, the symptom is: dir.c: In function 'git_url_basename': dir.c:3087:13: error: 'memchr' specified bound [9223372036854775808, 0] exceeds maximum object size 9223372036854775807 [-Werror=stringop-overread] CC ewah/bitmap.o 3087 | if (memchr(start, '/', end - start) == NULL | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ While it is a bit far-fetched to think that `end` (which is defined as `repo + strlen(repo)`) and `start` (which starts at `repo` and never steps beyond the NUL terminator) could result in such a negative difference, GCC has no way of knowing that. See also https://gcc.gnu.org/bugzilla//show_bug.cgi?id=85783. Let's just add a safety check, primarily for GCC's benefit. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 May 2022, 22:58:41 UTC
98cdb61 Johannes Schindelin 24 May 2022, 00:23:04 UTC nedmalloc: avoid new compile error GCC v12.x complains thusly: compat/nedmalloc/nedmalloc.c: In function 'DestroyCaches': compat/nedmalloc/nedmalloc.c:326:12: error: the comparison will always evaluate as 'true' for the address of 'caches' will never be NULL [-Werror=address] 326 | if(p->caches) | ^ compat/nedmalloc/nedmalloc.c:196:22: note: 'caches' declared here 196 | threadcache *caches[THREADCACHEMAXCACHES]; | ^~~~~~ ... and it is correct, of course. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 May 2022, 22:58:31 UTC
a6a243e Johannes Schindelin 24 May 2022, 00:23:03 UTC compat/win32/syslog: fix use-after-realloc Git for Windows' SDK recently upgraded to GCC v12.x which points out that the `pos` variable might be used even after the corresponding memory was `realloc()`ed and therefore potentially no longer valid. Since a subset of this SDK is used in Git's CI/PR builds, we need to fix this to continue to be able to benefit from the CI/PR runs. Note: This bug has been with us since 2a6b149c64f6 (mingw: avoid using strbuf in syslog, 2011-10-06), and while it looks tempting to replace the hand-rolled string manipulation with a `strbuf`-based one, that commit's message explains why we cannot do that: The `syslog()` function is called as part of the function in `daemon.c` which is set as the `die()` routine, and since `strbuf_grow()` can call that function if it runs out of memory, this would cause a nasty infinite loop that we do not want to re-introduce. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 May 2022, 22:58:22 UTC
b9063af Carlo Marcelo Arenas Belón 13 May 2022, 01:00:19 UTC t0034: add negative tests and allow git init to mostly work under sudo Add a support library that provides one function that can be used to run a "scriplet" of commands through sudo and that helps invoking sudo in the slightly awkward way that is required to ensure it doesn't block the call (if shell was allowed as tested in the prerequisite) and it doesn't run the command through a different shell than the one we intended. Add additional negative tests as suggested by Junio and that use a new workspace that is owned by root. Document a regression that was introduced by previous commits where root won't be able anymore to access directories they own unless SUDO_UID is removed from their environment. The tests document additional ways that this new restriction could be worked around and the documentation explains why it might be instead considered a feature, but a "fix" is planned for a future change. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 May 2022, 01:12:23 UTC
ae9abbb Carlo Marcelo Arenas Belón 13 May 2022, 01:00:18 UTC git-compat-util: avoid failing dir ownership checks if running privileged bdc77d1d685 (Add a function to determine whether a path is owned by the current user, 2022-03-02) checks for the effective uid of the running process using geteuid() but didn't account for cases where that user was root (because git was invoked through sudo or a compatible tool) and the original uid that repository trusted for its config was no longer known, therefore failing the following otherwise safe call: guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty [sudo] password for guy: fatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by someone else) Attempt to detect those cases by using the environment variables that those tools create to keep track of the original user id, and do the ownership check using that instead. This assumes the environment the user is running on after going privileged can't be tampered with, and also adds code to restrict that the new behavior only applies if running as root, therefore keeping the most common case, which runs unprivileged, from changing, but because of that, it will miss cases where sudo (or an equivalent) was used to change to another unprivileged user or where the equivalent tool used to raise privileges didn't track the original id in a sudo compatible way. Because of compatibility with sudo, the code assumes that uid_t is an unsigned integer type (which is not required by the standard) but is used that way in their codebase to generate SUDO_UID. In systems where uid_t is signed, sudo might be also patched to NOT be unsigned and that might be able to trigger an edge case and a bug (as described in the code), but it is considered unlikely to happen and even if it does, the code would just mostly fail safely, so there was no attempt either to detect it or prevent it by the code, which is something that might change in the future, based on expected user feedback. Reported-by: Guy Maurel <guy.j@maurel.de> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Randall Becker <rsbecker@nexbridge.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 May 2022, 01:12:23 UTC
5f1a3fe Carlo Marcelo Arenas Belón 13 May 2022, 01:00:17 UTC t: regression git needs safe.directory when using sudo Originally reported after release of v2.35.2 (and other maint branches) for CVE-2022-24765 and blocking otherwise harmless commands that were done using sudo in a repository that was owned by the user. Add a new test script with very basic support to allow running git commands through sudo, so a reproduction could be implemented and that uses only `git status` as a proxy of the issue reported. Note that because of the way sudo interacts with the system, a much more complete integration with the test framework will require a lot more work and that was therefore intentionally punted for now. The current implementation requires the execution of a special cleanup function which should always be kept as the last "test" or otherwise the standard cleanup functions will fail because they can't remove the root owned directories that are used. This also means that if failures are found while running, the specifics of the failure might not be kept for further debugging and if the test was interrupted, it will be necessary to clean the working directory manually before restarting by running: $ sudo rm -rf trash\ directory.t0034-root-safe-directory/ The test file also uses at least one initial "setup" test that creates a parallel execution directory under the "root" sub directory, which should be used as top level directory for all repositories that are used in this test file. Unlike all other tests the repository provided by the test framework should go unused. Special care should be taken when invoking commands through sudo, since the environment is otherwise independent from what the test framework setup and might have changed the values for HOME, SHELL and dropped several relevant environment variables for your test. Indeed `git status` was used as a proxy because it doesn't even require commits in the repository to work and usually doesn't require much from the environment to run, but a future patch will add calls to `git init` and that will fail to honor the default branch name, unless that setting is NOT provided through an environment variable (which means even a CI run could fail that test if enabled incorrectly). A new SUDO prerequisite is provided that does some sanity checking to make sure the sudo command that will be used allows for passwordless execution as root without restrictions and doesn't mess with git's execution path. This matches what is provided by the macOS agents that are used as part of GitHub actions and probably nowhere else. Most of those characteristics make this test mostly only suitable for CI, but it might be executed locally if special care is taken to provide for all of them in the local configuration and maybe making use of the sudo credential cache by first invoking sudo, entering your password if needed, and then invoking the test with: $ GIT_TEST_ALLOW_SUDO=YES ./t0034-root-safe-directory.sh If it fails to run, then it means your local setup wouldn't work for the test because of the configuration sudo has or other system settings, and things that might help are to comment out sudo's secure_path config, and make sure that the account you are using has no restrictions on the commands it can run through sudo, just like is provided for the user in the CI. For example (assuming a username of marta for you) something probably similar to the following entry in your /etc/sudoers (or equivalent) file: marta ALL=(ALL:ALL) NOPASSWD: ALL Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 May 2022, 01:12:23 UTC
f15e00b Ævar Arnfjörð Bjarmason 12 May 2022, 22:39:40 UTC ci: use https, not http to download binaries from perforce.com Since 522354d70f4 (Add Travis CI support, 2015-11-27) the CI has used http://filehost.perforce.com/perforce/ to download binaries from filehost.perforce.com, they were then moved to this script in 657343a602e (travis-ci: move Travis CI code into dedicated scripts, 2017-09-10). Let's use https instead for good measure. I don't think we need to worry about the DNS or network between the GitHub CI and perforce.com being MitM'd, but using https gives us extra validation of the payload at least, and is one less thing to worry about when checking where else we rely on non-TLS'd http connections. Also, use the same download site at perforce.com for Linux and macOS tarballs for consistency. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2022, 22:43:08 UTC
49af448 Carlo Marcelo Arenas Belón 12 May 2022, 22:39:39 UTC ci: reintroduce prevention from perforce being quarantined in macOS 5ed9fc3fc86 (ci: prevent `perforce` from being quarantined, 2020-02-27) introduces this prevention for brew, but brew has been removed in a previous commit, so reintroduce an equivalent option to avoid a possible regression. This doesn't affect github actions (as configure now) and is therefore done silently to avoid any possible scary irrelevant messages. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2022, 22:43:08 UTC
d1c9195 Carlo Marcelo Arenas Belón 12 May 2022, 22:39:38 UTC ci: avoid brew for installing perforce Perfoce's cask in brew is meant[1] to be used only by humans, so replace its use from the CI with a scripted binary download which is less likely to fail, as it is done in Linux. Kept the logic together so it will be less likely to break when moved around as on the fly code changes in this area are settled, at which point it will also feasable to ammend it to avoid some of the hardcoded values by using similar variables to the ones Linux does. In that same line, a POSIX sh syntax is used instead of the similar one used in Linux in preparation for an unrelated future change that might change the shell currently configured for it. This change reintroduces the risk that the installed binaries might not work because of being quarantined that was fixed with 5ed9fc3fc86 (ci: prevent `perforce` from being quarantined, 2020-02-27) but fixing that now was also punted for simplicity and since the affected cloud provider is scheduled to be retired with an on the fly change, but should be addressed if that other change is not integrated further. The discussion on the need to keep 2 radically different versions of the binaries to be tested with Linux vs macOS or how to upgrade to newer versions now that brew won't do that automatically for us has been punted for now as well. On that line the now obsolete comment about it in lib.sh was originally being updated by this change but created conflicts as it is moved around by other on the fly changes, so will be addressed independently as well. [1] https://github.com/Homebrew/homebrew-cask/pull/122347#discussion_r856026584 Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2022, 22:43:07 UTC
cde6b9b Carlo Marcelo Arenas Belón 12 May 2022, 22:39:37 UTC ci: make failure to find perforce more user friendly In preparation for a future change that will make perforce installation optional in macOS, make sure that the check for it is done without triggering scary looking errors and add a user friendly message instead. All other existing uses of 'type <cmd>' in our shell scripts that check the availability of a command <cmd> send both standard output and error stream to /dev/null to squelch "<cmd> not found" diagnostic output, but this script left the standard error stream shown. Redirect it just like everybody else to squelch this error message that we fully expect to see. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2022, 22:43:07 UTC
7c89855 Ævar Arnfjörð Bjarmason 12 May 2022, 22:32:17 UTC commit-graph.c: don't assume that stat() succeeds Fix code added in 8d84097f965 (commit-graph: expire commit-graph files, 2019-06-18) to check the return value of the stat() system call. Not doing so caused us to use uninitialized memory in the "Bloom generation is limited by --max-new-filters" test in t4216-log-bloom.sh: + rm -f trace.event + pwd + GIT_TRACE2_EVENT=[...]/t/trash directory.t4216-log-bloom/limits/trace.event git commit-graph write --reachable --split=replace --changed-paths --max-new-filters=2 ==24835== Syscall param utimensat(times[0].tv_sec) points to uninitialised byte(s) ==24835== at 0x499E65A: __utimensat64_helper (utimensat.c:34) ==24835== by 0x4999142: utime (utime.c:36) ==24835== by 0x552BE0: mark_commit_graphs (commit-graph.c:2213) ==24835== by 0x550822: write_commit_graph (commit-graph.c:2424) ==24835== by 0x54E3A0: write_commit_graph_reachable (commit-graph.c:1681) ==24835== by 0x4374BB: graph_write (commit-graph.c:269) ==24835== by 0x436F7D: cmd_commit_graph (commit-graph.c:326) ==24835== by 0x407B9A: run_builtin (git.c:465) ==24835== by 0x406651: handle_builtin (git.c:719) ==24835== by 0x407575: run_argv (git.c:786) ==24835== by 0x406410: cmd_main (git.c:917) ==24835== by 0x511F09: main (common-main.c:56) ==24835== Address 0x1ffeffde70 is on thread 1's stack ==24835== in frame #1, created by utime (utime.c:25) ==24835== Uninitialised value was created by a stack allocation ==24835== at 0x552B50: mark_commit_graphs (commit-graph.c:2201) ==24835== [...] error: last command exited with $?=126 not ok 137 - Bloom generation is limited by --max-new-filters This would happen as we stat'd the non-existing ".git/objects/info/commit-graph" file. Let's fix mark_commit_graphs() to check the stat()'s return value, and while we're at it fix another case added in the same commit to do the same. The caller in expire_commit_graphs() would have been less likely to run into this, as it's operating on files it just got from readdir(), but it could still happen due to a race with e.g. a concurrent "rm -rf" of the commit-graph files. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2022, 22:42:26 UTC
4627c67 Ævar Arnfjörð Bjarmason 12 May 2022, 22:32:18 UTC object-file: fix a unpack_loose_header() regression in 3b6a8db3b03 Fix a regression in my 3b6a8db3b03 (object-file.c: use "enum" return type for unpack_loose_header(), 2021-10-01) revealed both by running the test suite with --valgrind, and with the amended "git fsck" test. In practice this regression in v2.34.0 caused us to claim that we couldn't parse the header, as opposed to not being able to unpack it. Before the change in the C code the test_cmp added here would emit: -error: unable to unpack header of ./objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 +error: unable to parse header of ./objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 I.e. we'd proceed to call parse_loose_header() on the uninitialized "hdr" value, and it would have been very unlikely for that uninitialized memory to be a valid git object. The other callers of unpack_loose_header() were already checking the enum values exhaustively. See 3b6a8db3b03 and 5848fb11acd (object-file.c: return ULHR_TOO_LONG on "header too long", 2021-10-01). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2022, 22:42:26 UTC
29d8e21 Ævar Arnfjörð Bjarmason 12 May 2022, 22:32:16 UTC log test: skip a failing mkstemp() test under valgrind Skip a test added in f1e3df31699 (t: increase test coverage of signature verification output, 2020-03-04) when running under valgrind. Due to valgrind's interception of mkstemp() this test will fail with: + pwd + TMPDIR=[...]/t/trash directory.t4202-log/bogus git log --show-signature -n1 plain-fail ==7696== VG_(mkstemp): failed to create temp file: [...]/t/trash directory.t4202-log/bogus/valgrind_proc_7696_cmdline_d545ddcf [... 10 more similar lines omitted ..] valgrind: Startup or configuration error: valgrind: Can't create client cmdline file in [...]/t/trash directory.t4202-log/bogus/valgrind_proc_7696_cmdline_6e542d1d valgrind: Unable to start up properly. Giving up. error: last command exited with $?=1 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2022, 22:42:26 UTC
58407e0 Ævar Arnfjörð Bjarmason 12 May 2022, 22:32:15 UTC tests: using custom GIT_EXEC_PATH breaks --valgrind tests Fix a regression in b7d11a0f5d2 (tests: exercise the RUNTIME_PREFIX feature, 2021-07-24) where tests that want to set up and test a "git" wrapper in $PATH conflicted with the t/bin/valgrind wrapper(s) doing the same. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2022, 22:42:26 UTC
6a61661 Junio C Hamano 12 May 2022, 21:31:09 UTC archive: do not let on-disk mode leak to zip archives When the "--add-file" option is used to add the contents from an untracked file to the archive, the permission mode bits for these files are sent to the archive-backend specific "write_entry()" method as-is. We normalize the mode bits for tracked files way before we pass them to the write_entry() method; we should do the same here. This is not strictly needed for "tar" archive-backend, as it has its own code to further clean them up, but "zip" archive-backend is not so well prepared. Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 May 2022, 21:32:25 UTC
b014cee Junio C Hamano 11 May 2022, 15:10:12 UTC SubmittingPatches: use more stable git.ozlabs.org URL Signed-off-by: Junio C Hamano <gitster@pobox.com> 11 May 2022, 15:19:08 UTC
1fbfd96 Michael J Gruber 09 May 2022, 11:22:02 UTC detect-compiler: make detection independent of locale `detect-compiler` has accumulated a few compiler dependent workarounds lately for the more and more ubiquitious gcc12. This is intended to make CI set-ups work across tool-chain updates, but also help those developers who build with `DEVELOPER=1`. Alas, `detect-compiler` uses the locale dependent output of `$(CC) -v` to parse for the version string, which fails unless it literally contains ` version`. Use `LANG=C $(CC) -v` instead to grep for stable output. Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 May 2022, 15:52:26 UTC
e54793a Junio C Hamano 05 May 2022, 21:36:37 UTC Git 2.36.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 May 2022, 21:36:37 UTC
565442c Junio C Hamano 05 May 2022, 21:36:25 UTC Merge branch 'ab/cc-package-fixes' into maint Correct choices of C compilers used in various CI jobs. source: <patch-v3-1.1-8b3444ecc87-20220422T092015Z-avarab@gmail.com> * ab/cc-package-fixes: CI: select CC based on CC_PACKAGE (again) 05 May 2022, 21:36:25 UTC
c038dd6 Junio C Hamano 05 May 2022, 21:36:25 UTC Merge branch 'jc/cocci-xstrdup-or-null-fix' into maint Get rid of a bogus and over-eager coccinelle rule. source: <xmqq1qxd6e4x.fsf@gitster.g> * jc/cocci-xstrdup-or-null-fix: cocci: drop bogus xstrdup_or_null() rule 05 May 2022, 21:36:25 UTC
676cead Junio C Hamano 05 May 2022, 21:36:25 UTC Merge branch 'rs/format-patch-pathspec-fix' into maint "git format-patch <args> -- <pathspec>" lost the pathspec when showing the second and subsequent commits, which has been corrected. source: <c36896a1-6247-123b-4fa3-b7eb24af1897@web.de> * rs/format-patch-pathspec-fix: 2.36 format-patch regression fix 05 May 2022, 21:36:25 UTC
09a2302 Junio C Hamano 05 May 2022, 21:36:25 UTC Merge branch 'rs/fast-export-pathspec-fix' into maint "git fast-export -- <pathspec>" lost the pathspec when showing the second and subsequent commits, which has been corrected. source: <2c988c7b-0efe-4222-4a43-8124fe1a9da6@web.de> * rs/fast-export-pathspec-fix: 2.36 fast-export regression fix 05 May 2022, 21:36:25 UTC
8da1481 Junio C Hamano 05 May 2022, 21:36:24 UTC Merge branch 'jc/show-pathspec-fix' into maint "git show <commit1> <commit2>... -- <pathspec>" lost the pathspec when showing the second and subsequent commits, which has been corrected. source: <xmqqo80j87g0.fsf_-_@gitster.g> * jc/show-pathspec-fix: 2.36 show regression fix 05 May 2022, 21:36:24 UTC
ee12682 Junio C Hamano 05 May 2022, 21:36:24 UTC Merge branch 'rs/name-rev-fix-free-after-use' into maint Regression fix for 2.36 where "git name-rev" started to sometimes reference strings after they are freed. This fixes a regression in 2.36 and is slate to go to 2.36.1 source: <340c8810-d912-7b18-d46e-a9d43f20216a@web.de> * rs/name-rev-fix-free-after-use: Revert "name-rev: release unused name strings" 05 May 2022, 21:36:24 UTC
8e5c46e Junio C Hamano 05 May 2022, 21:36:24 UTC Merge branch 'jc/diff-tree-stdin-fix' into maint "diff-tree --stdin" has been broken for about a year, but 2.36 release broke it even worse by breaking running the command with <pathspec>, which in turn broke "gitk" and got noticed. This has been corrected by aligning its behaviour to that of "log". This fixes a regression in 2.36 and is slate to go to 2.36.1 source: <xmqq7d7bsu2n.fsf@gitster.g> * jc/diff-tree-stdin-fix: 2.36 gitk/diff-tree --stdin regression fix 05 May 2022, 21:36:24 UTC
899df5f Junio C Hamano 05 May 2022, 21:36:24 UTC Merge branch 'gc/submodule-update-part2' into maint "git submodule update" without pathspec should silently skip an uninitialized submodule, but it started to become noisy by mistake. This fixes a regression in 2.36 and is slate to go to 2.36.1 source: <pull.1258.v2.git.git.1650890741430.gitgitgadget@gmail.com> * gc/submodule-update-part2: submodule--helper: fix initialization of warn_if_uninitialized 05 May 2022, 21:36:24 UTC
08bdd3a Junio C Hamano 01 May 2022, 05:00:30 UTC cocci: drop bogus xstrdup_or_null() rule 13092a91 (cocci: refactor common patterns to use xstrdup_or_null(), 2016-10-12) introduced a rule to rewrite this conditional call to xstrdup(E) and an assignment to variable V: - if (E) - V = xstrdup(E); into an unconditional call to xstrdup_or_null(E) and an assignment to variable V: + V = xstrdup_or_null(E); which is utterly bogus. The original code may already have an acceptable value in V and the conditional assignment may be to improve the value already in V with a copy of a better value E when (and only when) E is not NULL. The rewritten construct unconditionally discards the existing value of V and replaces it with a copy of E, even when E is NULL, which changes the meaning of the program. By the way, if it were -if (E && !V) - V = xstrdup(E); +V = xstrdup_or_null(E); it would probably have been correct. But there is no existing code that would have been improved by such a rule, so let's just remove the bogus one without replacing with the more specific one. Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 May 2022, 05:23:11 UTC
6dfadc8 Junio C Hamano 01 May 2022, 05:17:15 UTC clone: plug a miniscule leak The remote_name variable is first assigned a copy of the value of the "clone.defaultremotename" configuration variable and then by the value of the "--origin" command line option. The former is prepared to see multiple instances of the configuration variable by freeing the current value of the variable before a copy of the newly discovered value gets assigned to it. The latter however blindly assigned a copy of the new value to the variable, thereby leaking the value read from the configuration variable. Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 May 2022, 05:22:12 UTC
d1c2527 René Scharfe 30 April 2022, 14:31:43 UTC 2.36 fast-export regression fix e900d494dc (diff: add an API for deferred freeing, 2021-02-11) added a way to allow reusing diffopts: the no_free bit. 244c27242f (diff.[ch]: have diff_free() call clear_pathspec(opts.pathspec), 2022-02-16) made that mechanism mandatory. git fast-export doesn't set no_free, so path limiting stopped working after the first commit. Set the flag and add a basic test to make sure only changes to the specified files are exported. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 April 2022, 18:50:33 UTC
91f8f7e René Scharfe 30 April 2022, 10:32:44 UTC 2.36 format-patch regression fix e900d494dc (diff: add an API for deferred freeing, 2021-02-11) added a way to allow reusing diffopts: the no_free bit. 244c27242f (diff.[ch]: have diff_free() call clear_pathspec(opts.pathspec), 2022-02-16) made that mechanism mandatory. git format-patch only sets no_free when --output is given, causing it to forget pathspecs after the first commit. Set no_free unconditionally instead. The existing test was unable to detect this breakage because it checks stderr for the absence of a certain string, but format-patch writes to stdout. Also the test was not checking the case of one commit modifying multiple files and a pathspec limiting the diff. Replace it with a more thorough one. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 April 2022, 18:49:59 UTC
5cdb384 Junio C Hamano 30 April 2022, 05:29:51 UTC 2.36 show regression fix This only surfaced as a regression after 2.36 release, but the breakage was already there with us for at least a year. e900d494 (diff: add an API for deferred freeing, 2021-02-11) introduced a mechanism to delay freeing resources held in diff_options struct that need to be kept as long as the struct will be reused to compute diff. "git log -p" was taught to utilize the mechanism but it was done with an incorrect assumption that the underlying helper function, cmd_log_walk(), is called only once, and it is OK to do the freeing at the end of it. Alas, for "git show A B", the function is called once for each commit given, so it is not OK to free the resources until we finish calling it for all the commits given from the command line. During 2.36 release cycle, we started clearing the <pathspec> as part of this freeing, which made the bug a lot more visible. Fix this breakage by tweaking how cmd_log_walk() frees the resources at the end and using a variant of it that does not immediately free the resources to show each commit object from the command line in "git show". Protect the fix with a few new tests. Reported-by: Daniel Li <dan@danielyli.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 April 2022, 05:31:17 UTC
4f1ccef Orgad Shaneh 25 April 2022, 12:45:41 UTC submodule--helper: fix initialization of warn_if_uninitialized 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> 26 April 2022, 18:14:10 UTC
f8781bf Junio C Hamano 26 April 2022, 16:11:44 UTC 2.36 gitk/diff-tree --stdin regression fix 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> 26 April 2022, 16:26:35 UTC
11f9e8d Derrick Stolee 25 April 2022, 18:27:14 UTC cache: use const char * for get_object_directory() The get_object_directory() method returns the exact string stored at the_repository->objects->odb->path. The return type of "char *" implies that the caller must keep track of the buffer and free() it when complete. This causes significant problems later when the ODB is accessed. Use "const char *" as the return type to avoid this confusion. There are no current callers that care about the non-const definition. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 April 2022, 18:31:13 UTC
b56166c Derrick Stolee 25 April 2022, 18:27:13 UTC multi-pack-index: use --object-dir real path The --object-dir argument to 'git multi-pack-index' allows a user to specify an alternate to use instead of the local $GITDIR. This is used by third-party tools like VFS for Git to maintain the pack-files in a "shared object cache" used by multiple clones. On Windows, the user can specify a path using a Windows-style file path with backslashes such as "C:\Path\To\ObjectDir". This same path style is used in the .git/objects/info/alternates file, so it already matches the path of that alternate. However, find_odb() converts these paths to real-paths for the comparison, which use forward slashes. As of the previous change, lookup_multi_pack_index() uses real-paths, so it correctly finds the target multi-pack-index when given these paths. Some commands such as 'git multi-pack-index repack' call child processes using the object_dir value, so it can be helpful to convert the path to the real-path before sending it to those locations. Add a callback to convert the real path immediately upon parsing the argument. We need to be careful that we don't store the exact value out of get_object_directory() and free it, or we could corrupt a later use of the_repository->objects->odb->path. We don't use get_object_directory() for the initial instantiation in cmd_multi_pack_index() because we need 'git multi-pack-index -h' to work without a Git repository. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 April 2022, 18:31:12 UTC
eafcc6d Derrick Stolee 25 April 2022, 18:27:12 UTC midx: use real paths in lookup_multi_pack_index() This helper looks for a parsed multi-pack-index whose object directory matches the given object_dir. Before going into the loop over the parsed multi-pack-indexes, it calls find_odb() to ensure that the given object_dir is actually a known object directory. However, find_odb() uses real-path manipulations to compare the input to the alternate directories. This same real-path comparison is not used in the loop, leading to potential issues with the strcmp(). Update the method to use the real-path values instead. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 April 2022, 18:31:11 UTC
45a14f5 René Scharfe 22 April 2022, 18:44:40 UTC Revert "name-rev: release unused name strings" 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> 23 April 2022, 16:46:40 UTC
3506cae Ævar Arnfjörð Bjarmason 22 April 2022, 09:20:53 UTC CI: select CC based on CC_PACKAGE (again) Fix a regression in 707d2f2fe86 (CI: use "$runs_on_pool", not "$jobname" to select packages & config, 2021-11-23). In that commit I changed CC=gcc from CC=gcc-9, but on OSX the "gcc" in $PATH points to clang, we need to use gcc-9 instead. Likewise for the linux-gcc job CC=gcc-8 was changed to the implicit CC=gcc, which would select GCC 9.4.0 instead of GCC 8.4.0. Furthermore in 25715419bf4 (CI: don't run "make test" twice in one job, 2021-11-23) when the "linux-TEST-vars" job was split off from "linux-gcc" the "cc_package: gcc-8" line was copied along with it, so its "cc_package" line wasn't working as intended either. As a table, this is what's changed by this commit, i.e. it only affects the linux-gcc, linux-TEST-vars and osx-gcc jobs: |-------------------+-----------+-------------------+-------+-------| | jobname | vector.cc | vector.cc_package | old | new | |-------------------+-----------+-------------------+-------+-------| | linux-clang | clang | - | clang | clang | | linux-sha256 | clang | - | clang | clang | | linux-gcc | gcc | gcc-8 | gcc | gcc-8 | | osx-clang | clang | - | clang | clang | | osx-gcc | gcc | gcc-9 | clang | gcc-9 | | linux-gcc-default | gcc | - | gcc | gcc | | linux-TEST-vars | gcc | gcc-8 | gcc | gcc-8 | |-------------------+-----------+-------------------+-------+-------| Reported-by: Carlo Arenas <carenas@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 April 2022, 18:28:17 UTC
41c64ae Junio C Hamano 21 April 2022, 21:25:47 UTC show-branch: -g and --current are incompatible When "--current" is given to "git show-branch" running in the "--reflog" mode, the code tries to reference a "reflog" message that does not even exist. This is because the --current is not prepared to work in that mode. The reason "--current" exists is to support this request: I list branches on the command line. These are the branchesI care about and I use as anchoring points. I may or may not be on one of these main branches. Please make sure I can view the commits on the current branch with respect to what is in these other branches. And to serve that request, the code checks if the current branch is among the ones listed on the command line, and adds it only if it is not to the end of one array, which essentially lists the objects. The reflog mode additionally uses another array to list reflog messages, which the "--current" code does not add to. This leaves one uninitialized slot at the end of the array of reflog messages, and causes the program to show garbage or segfault. Catch the unsupported (and meaningless) combination and exit with a usage error. There are other combinations of options that are incompatible but have not been tested. Add test to cover them while adding coverage for this new combination. Reported-by: Gregory David <gregory.david@p1sec.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 April 2022, 21:26:42 UTC
9e5ebe9 Alex Henrie 21 April 2022, 04:42:33 UTC rebase: use correct base for --keep-base when a branch is given --keep-base rebases onto the merge base of the given upstream and the current HEAD regardless of whether a branch is given. This is contrary to the documentation and to the option's intended purpose. Instead, rebase onto the merge base of the given upstream and the given branch. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 April 2022, 16:35:45 UTC
6cd33dc Junio C Hamano 18 April 2022, 05:21:51 UTC Git 2.36 Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 April 2022, 05:21:51 UTC
b908065 Junio C Hamano 18 April 2022, 05:20:49 UTC Merge tag 'l10n-2.36.0-rnd2.1' of https://github.com/git-l10n/git-po l10n-2.36.0-rnd2.1 * tag 'l10n-2.36.0-rnd2.1' of https://github.com/git-l10n/git-po: l10n: sv.po: Update Swedish translation (5282t0f0u) l10n: Update Catalan translation l10n: po-id for 2.36 (round 2) l10n: de.po: Update German translation l10n: zh_CN v2.36.0 round 2 l10n: pt_PT: update Portuguese translation l10n: vi(5285t): v2.36.0 round 2 l10n: zh_TW: v2.36.0 round 2 l10n: fr: v2.36 round 2 l10n: tr: v2.36.0 round 2 l10n: git.pot: v2.36.0 round 2 (4 new, 3 removed) l10n: fr: v2.36 round 1 l10n: zh_CN v2.36.0 round 1 l10n: Update zh_CN repo link l10n: po-id for 2.36 (round 1) l10n: tr: v2.36.0 round 1 l10n: git.pot: v2.36.0 round 1 (192 new, 106 removed) l10n: pt_PT: update TEAMS file l10n: pt_PT: update Portuguese translation 18 April 2022, 05:20:49 UTC
db4361b Junio C Hamano 17 April 2022, 23:32:05 UTC Merge branch 'cb/buggy-gcc-12-workaround' A couple of work around for CI breaking warnings from gcc 12. * cb/buggy-gcc-12-workaround: config.mak.dev: alternative workaround to gcc 12 warning in http.c config.mak.dev: workaround gcc 12 bug affecting "pedantic" CI job 17 April 2022, 23:32:05 UTC
9b23d2c Peter Krefting 17 April 2022, 17:13:34 UTC l10n: sv.po: Update Swedish translation (5282t0f0u) Signed-off-by: Peter Krefting <peter@softwolves.pp.se> 17 April 2022, 17:13:34 UTC
1208041 Jiang Xin 17 April 2022, 01:07:28 UTC Merge branch 'master' of github.com:Softcatala/git-po * 'master' of github.com:Softcatala/git-po: l10n: Update Catalan translation 17 April 2022, 01:07:28 UTC
ac87f96 Jordi Mas 16 April 2022, 18:17:17 UTC l10n: Update Catalan translation Signed-off-by: Jordi Mas <jmas@softcatala.org> 16 April 2022, 18:17:17 UTC
aac04e0 Bagas Sanjaya 14 April 2022, 06:40:35 UTC l10n: po-id for 2.36 (round 2) 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> 16 April 2022, 10:04:26 UTC
9c539d1 Carlo Marcelo Arenas Belón 15 April 2022, 23:13:42 UTC config.mak.dev: alternative workaround to gcc 12 warning in http.c 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> 15 April 2022, 23:27:04 UTC
846a29a Carlo Marcelo Arenas Belón 15 April 2022, 23:13:41 UTC config.mak.dev: workaround gcc 12 bug affecting "pedantic" CI job 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> 15 April 2022, 23:26:16 UTC
c616d18 Jiang Xin 15 April 2022, 00:26:53 UTC Merge branch 'master' of github.com:ruester/git-po-de * 'master' of github.com:ruester/git-po-de: l10n: de.po: Update German translation 15 April 2022, 00:26:53 UTC
cb6da32 Jiang Xin 15 April 2022, 00:26:06 UTC Merge branch 'fz/po-2.36.0-round2' of github.com:fangyi-zhou/git-po * 'fz/po-2.36.0-round2' of github.com:fangyi-zhou/git-po: l10n: zh_CN v2.36.0 round 2 15 April 2022, 00:26:06 UTC
4027e30 Junio C Hamano 14 April 2022, 21:17:12 UTC Merge branch 'jc/revert-ref-transaction-hook-changes' Revert the "deletion of a ref should not trigger transaction events for loose and packed ref backends separately" that regresses the behaviour when a ref is not modified since it was packed. * jc/revert-ref-transaction-hook-changes: RelNotes: revert the description on the reverted topics Revert "fetch: increase test coverage of fetches" Revert "Merge branch 'ps/avoid-unnecessary-hook-invocation-with-packed-refs'" 14 April 2022, 21:17:12 UTC
b32632c Junio C Hamano 14 April 2022, 21:17:12 UTC Merge branch 'jc/relnotes-updates' Wording updates for 2.36 release notes. * jc/relnotes-updates: RelNotes: mention safe.directory RelNotes: clarify "bisect run unexecutable" tweak 14 April 2022, 21:17:12 UTC
4ac22f8 Matthias Rüster 09 April 2022, 15:57:47 UTC l10n: de.po: Update German translation 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> 14 April 2022, 15:03:02 UTC
40f3541 Fangyi Zhou 14 April 2022, 14:46:21 UTC l10n: zh_CN v2.36.0 round 2 Signed-off-by: Fangyi Zhou <me@fangyi.io> 14 April 2022, 14:49:18 UTC
b3717a8 Daniel Santos 23 February 2022, 19:39:47 UTC l10n: pt_PT: update Portuguese translation * 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> 14 April 2022, 11:09:07 UTC
2a7f398 Tran Ngoc Quan 14 April 2022, 06:58:46 UTC l10n: vi(5285t): v2.36.0 round 2 Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com> 14 April 2022, 08:34:48 UTC
dd6cf19 Jiang Xin 14 April 2022, 05:13:38 UTC Merge branch 'loc/tw/0407' of github.com:l10n-tw/git-po * 'loc/tw/0407' of github.com:l10n-tw/git-po: l10n: zh_TW: v2.36.0 round 2 14 April 2022, 05:13:38 UTC
c9f01d5 Yi-Jyun Pan 07 April 2022, 06:30:49 UTC l10n: zh_TW: v2.36.0 round 2 Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com> 14 April 2022, 00:07:08 UTC
4315986 Junio C Hamano 13 April 2022, 23:55:36 UTC RelNotes: revert the description on the reverted topics Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 23:55:36 UTC
255ede9 Junio C Hamano 13 April 2022, 23:51:41 UTC RelNotes: mention safe.directory Helped-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 23:51:41 UTC
26ff9be Junio C Hamano 13 April 2022, 23:42:33 UTC RelNotes: clarify "bisect run unexecutable" tweak 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> 13 April 2022, 23:42:33 UTC
347cc1b Junio C Hamano 13 April 2022, 22:58:04 UTC Revert "fetch: increase test coverage of fetches" 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. 13 April 2022, 22:58:04 UTC
c6da34a Junio C Hamano 13 April 2022, 22:51:33 UTC Revert "Merge branch 'ps/avoid-unnecessary-hook-invocation-with-packed-refs'" This reverts commit 991b4d47f0accd3955d05927d5ce434e03ffbdb6, reversing changes made to bcd020f88e1e22f38422ac3f73ab06b34ec4bef1. 13 April 2022, 22:51:33 UTC
1ac7422 Junio C Hamano 13 April 2022, 22:26:32 UTC Sync with Git 2.35.3 13 April 2022, 22:26:32 UTC
d516b2d Junio C Hamano 13 April 2022, 22:21:34 UTC Git 2.35.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 22:21:34 UTC
2f0dde7 Junio C Hamano 13 April 2022, 22:21:31 UTC Git 2.34.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 22:21:31 UTC
1f65dd6 Junio C Hamano 13 April 2022, 22:21:28 UTC Git 2.33.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 22:21:28 UTC
1530434 Junio C Hamano 13 April 2022, 22:21:26 UTC Git 2.32.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 April 2022, 22:21:26 UTC
back to top