| 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 |
| 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 |
| 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 |
| 09f66d6 | Junio C Hamano | 13 April 2022, 22:21:08 UTC | Git 2.31.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 22:21:08 UTC |
| 17083c7 | Junio C Hamano | 13 April 2022, 20:31:29 UTC | Git 2.30.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 April 2022, 20:31:29 UTC |
| 0f85c4a | Derrick Stolee | 13 April 2022, 15:32:31 UTC | setup: opt-out of check with safe.directory=* 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> | 13 April 2022, 19:42:51 UTC |
| bb50ec3 | Matheus Valadares | 13 April 2022, 15:32:30 UTC | setup: fix safe.directory key not being checked 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> | 13 April 2022, 19:42:51 UTC |
| e47363e | Derrick Stolee | 13 April 2022, 15:32:29 UTC | t0033: add tests for safe.directory 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> | 13 April 2022, 19:42:49 UTC |
| 53ef17d | Johannes Schindelin | 17 March 2022, 09:58:00 UTC | Git 2.35.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 March 2022, 23:31:43 UTC |
| 1f480d5 | Johannes Schindelin | 17 March 2022, 09:57:59 UTC | Sync with 2.34.2 * maint-2.34: Git 2.34.2 Git 2.33.2 Git 2.32.1 Git 2.31.2 GIT-VERSION-GEN: bump to v2.33.1 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user | 23 March 2022, 23:31:42 UTC |
| 4d0b43a | Johannes Schindelin | 17 March 2022, 09:57:52 UTC | Git 2.34.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 March 2022, 23:31:36 UTC |
| 93fbff0 | Johannes Schindelin | 17 March 2022, 09:57:50 UTC | Sync with 2.33.2 * maint-2.33: Git 2.33.2 Git 2.32.1 Git 2.31.2 GIT-VERSION-GEN: bump to v2.33.1 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user | 23 March 2022, 23:31:36 UTC |
| 87ed4fc | Johannes Schindelin | 17 March 2022, 09:57:44 UTC | Git 2.33.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 March 2022, 23:31:32 UTC |
| 303b876 | Johannes Schindelin | 17 March 2022, 09:57:43 UTC | Sync with 2.32.1 * maint-2.32: Git 2.32.1 Git 2.31.2 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user | 23 March 2022, 23:31:32 UTC |
| 9bcd7a8 | Johannes Schindelin | 17 March 2022, 09:57:38 UTC | Git 2.32.1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 March 2022, 23:31:29 UTC |
| 201b0c7 | Johannes Schindelin | 17 March 2022, 09:57:37 UTC | Sync with 2.31.2 * maint-2.31: Git 2.31.2 Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user | 23 March 2022, 23:31:28 UTC |
| 44de39c | Johannes Schindelin | 17 March 2022, 09:57:32 UTC | Git 2.31.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 March 2022, 23:24:29 UTC |
| 6a2381a | Johannes Schindelin | 17 March 2022, 09:57:31 UTC | Sync with 2.30.3 * maint-2.30: Git 2.30.3 setup_git_directory(): add an owner check for the top-level directory Add a function to determine whether a path is owned by the current user | 23 March 2022, 23:24:29 UTC |
| cb95038 | Johannes Schindelin | 17 March 2022, 09:15:15 UTC | Git 2.30.3 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 March 2022, 23:22:17 UTC |
| fdcad5a | Johannes Schindelin | 23 March 2022, 22:00:41 UTC | Fix `GIT_CEILING_DIRECTORIES` with `C:\` and the likes When determining the length of the longest ancestor of a given path with respect to to e.g. `GIT_CEILING_DIRECTORIES`, we special-case the root directory by returning 0 (i.e. we pretend that the path `/` does not end in a slash by virtually stripping it). That is the correct behavior because when normalizing paths, the root directory is special: all other directory paths have their trailing slash stripped, but not the root directory's path (because it would become the empty string, which is not a legal path). However, this special-casing of the root directory in `longest_ancestor_length()` completely forgets about Windows-style root directories, e.g. `C:\`. These _also_ get normalized with a trailing slash (because `C:` would actually refer to the current directory on that drive, not necessarily to its root directory). In fc56c7b34b (mingw: accomodate t0060-path-utils for MSYS2, 2016-01-27), we almost got it right. We noticed that `longest_ancestor_length()` expects a slash _after_ the matched prefix, and if the prefix already ends in a slash, the normalized path won't ever match and -1 is returned. But then that commit went astray: The correct fix is not to adjust the _tests_ to expect an incorrect -1 when that function is fed a prefix that ends in a slash, but instead to treat such a prefix as if the trailing slash had been removed. Likewise, that function needs to handle the case where it is fed a path that ends in a slash (not only a prefix that ends in a slash): if it matches the prefix (plus trailing slash), we still need to verify that the path does not end there, otherwise the prefix is not actually an ancestor of the path but identical to it (and we need to return -1 in that case). With these two adjustments, we no longer need to play games in t0060 where we only add `$rootoff` if the passed prefix is different from the MSYS2 pseudo root, instead we also add it for the MSYS2 pseudo root itself. We do have to be careful to skip that logic entirely for Windows paths, though, because they do are not subject to that MSYS2 pseudo root treatment. This patch fixes the scenario where a user has set `GIT_CEILING_DIRECTORIES=C:\`, which would be ignored otherwise. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 23 March 2022, 23:21:08 UTC |
| 8959555 | Johannes Schindelin | 02 March 2022, 11:23:04 UTC | setup_git_directory(): add an owner check for the top-level directory It poses a security risk to search for a git directory outside of the directories owned by the current user. For example, it is common e.g. in computer pools of educational institutes to have a "scratch" space: a mounted disk with plenty of space that is regularly swiped where any authenticated user can create a directory to do their work. Merely navigating to such a space with a Git-enabled `PS1` when there is a maliciously-crafted `/scratch/.git/` can lead to a compromised account. The same holds true in multi-user setups running Windows, as `C:\` is writable to every authenticated user by default. To plug this vulnerability, we stop Git from accepting top-level directories owned by someone other than the current user. We avoid looking at the ownership of each and every directories between the current and the top-level one (if there are any between) to avoid introducing a performance bottleneck. This new default behavior is obviously incompatible with the concept of shared repositories, where we expect the top-level directory to be owned by only one of its legitimate users. To re-enable that use case, we add support for adding exceptions from the new default behavior via the config setting `safe.directory`. The `safe.directory` config setting is only respected in the system and global configs, not from repository configs or via the command-line, and can have multiple values to allow for multiple shared repositories. We are particularly careful to provide a helpful message to any user trying to use a shared repository. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 21 March 2022, 12:16:26 UTC |
| bdc77d1 | Johannes Schindelin | 02 March 2022, 10:06:24 UTC | Add a function to determine whether a path is owned by the current user This function will be used in the next commit to prevent `setup_git_directory()` from discovering a repository in a directory that is owned by someone other than the current user. Note: We cannot simply use `st.st_uid` on Windows just like we do on Linux and other Unix-like platforms: according to https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions this field is always zero on Windows (because Windows' idea of a user ID does not fit into a single numerical value). Therefore, we have to do something a little involved to replicate the same functionality there. Also note: On Windows, a user's home directory is not actually owned by said user, but by the administrator. For all practical purposes, it is under the user's control, though, therefore we pretend that it is owned by the user. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 21 March 2022, 12:16:26 UTC |
| 2a9a586 | Johannes Schindelin | 17 March 2022, 11:52:12 UTC | Merge branch 'cb/mingw-gmtime-r' Build fix on Windows. * cb/mingw-gmtime-r: mingw: avoid fallback for {local,gm}time_r() Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 17 March 2022, 11:52:12 UTC |
| 6e7ad1e | Carlo Marcelo Arenas Belón | 27 November 2021, 10:15:32 UTC | mingw: avoid fallback for {local,gm}time_r() mingw-w64's pthread_unistd.h had a bug that mistakenly (because there is no support for the *lockfile() functions required[1]) defined _POSIX_THREAD_SAFE_FUNCTIONS and that was being worked around since 3ecd153a3b (compat/mingw: support MSys2-based MinGW build, 2016-01-14). The bug was fixed in winphtreads, but as a side effect, leaves the reentrant functions from time.h no longer visible and therefore breaks the build. Since the intention all along was to avoid using the fallback functions, formalize the use of POSIX by setting the corresponding feature flag and compile out the implementation for the fallback functions. [1] https://unix.org/whitepapers/reentrant.html Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 17 March 2022, 11:52:12 UTC |
| 898225b | Johannes Schindelin | 17 March 2022, 09:35:52 UTC | GIT-VERSION-GEN: bump to v2.33.1 This was missed in af6d1d602a8f (Git 2.33.1, 2021-10-12). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 17 March 2022, 09:35:52 UTC |
| 4c53a8c | Junio C Hamano | 29 January 2022, 00:48:42 UTC | Git 2.35.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 29 January 2022, 00:48:42 UTC |
| f120b65 | Junio C Hamano | 29 January 2022, 00:45:39 UTC | Merge branch 'en/keep-cwd' into maint Fix a regression in 2.35 that roke the use of "rebase" and "stash" in a secondary worktree. * en/keep-cwd: sequencer, stash: fix running from worktree subdir | 29 January 2022, 00:45:52 UTC |
| ff5b791 | Elijah Newren | 26 January 2022, 01:43:45 UTC | sequencer, stash: fix running from worktree subdir In commits bc3ae46b42 ("rebase: do not attempt to remove startup_info->original_cwd", 2021-12-09) and 0fce211ccc ("stash: do not attempt to remove startup_info->original_cwd", 2021-12-09), we wanted to allow the subprocess to know which directory the parent process was running from, so that the subprocess could protect it. However... When run from a non-main worktree, setup_git_directory() will note that the discovered git directory (/PATH/TO/.git/worktree/non-main-worktree) does not match DEFAULT_GIT_DIR_ENVIRONMENT (see setup_discovered_git_dir()), and decide to set GIT_DIR in the environment. This matters because... Whenever git is run with the GIT_DIR environment variable set, and GIT_WORK_TREE not set, it presumes that '.' is the working tree. So... This combination results in the subcommand being very confused about the working tree. Fix it by also setting the GIT_WORK_TREE environment variable along with setting cmd.dir. A possibly more involved fix we could consider for later would be to make setup.c set GIT_WORK_TREE whenever (a) it discovers both the git directory and the working tree and (b) it decides to set GIT_DIR in the environment. I did not attempt that here as such would be too big of a change for a 2.35.1 release. Test-case-by: Glen Choo <chooglen@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 26 January 2022, 20:01:54 UTC |
| 89bece5 | Junio C Hamano | 24 January 2022, 17:25:25 UTC | Git 2.35 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 24 January 2022, 17:25:25 UTC |
| c6e19e4 | Junio C Hamano | 24 January 2022, 17:14:46 UTC | Merge branch 'ab/checkout-branch-info-leakfix' We added an unrelated sanity checking that leads to a BUG() while plugging a leak, which triggered in a repository with symrefs in the local branch namespace that point at a ref outside. Partially revert the change to avoid triggering the BUG(). * ab/checkout-branch-info-leakfix: checkout: avoid BUG() when hitting a broken repository | 24 January 2022, 17:14:46 UTC |
| 7ea759c | Junio C Hamano | 24 January 2022, 17:09:34 UTC | Merge tag 'l10n-2.35.0-rnd2' of git://github.com/git-l10n/git-po l10n-2.35.0-rnd2 * tag 'l10n-2.35.0-rnd2' of git://github.com/git-l10n/git-po: l10n: Update Catalan translation l10n: zh_TW: v2.35.0 round 2 (0 untranslated) l10n: Update Catalan translation l10n: de.po: Update German translation l10n: de.po: Fix translation for "'%s' is aliased to '%s'" l10n: po-id for 2.35 (round 2) l10n: Update Catalan translation l10n: vi(5195t): Update for v2.35.0 round 2 l10n: batch update to fix typo in branch.c l10n: git.pot: v2.35.0 round 2 (1 new, 1 removed) l10n: bg.po: Updated Bulgarian translation (5195t) l10n: zh_CN: v2.35.0 round 1 l10n: fr: v2.35.0 round 1 l10n: zh_TW: v2.35.0 round 1 (1 fuzzy) l10n: po-id for 2.35 (round 1) l10n: sv.po: Update Swedish translation (5196t0f0u) l10n: sv.po: Fix typo l10n: tr: v2.35.0 round 1 l10n: git.pot: v2.35.0 round 1 (126 new, 142 removed) | 24 January 2022, 17:09:34 UTC |
| 9e2b35d | Jordi Mas | 23 January 2022, 08:40:52 UTC | l10n: Update Catalan translation Signed-off-by: Jordi Mas <jmas@softcatala.org> | 23 January 2022, 08:40:52 UTC |
| 0fff4ea | Jiang Xin | 22 January 2022, 08:27:41 UTC | Merge branch 'l10n/zh_TW/220113' of github.com:l10n-tw/git-po * 'l10n/zh_TW/220113' of github.com:l10n-tw/git-po: l10n: zh_TW: v2.35.0 round 2 (0 untranslated) l10n: zh_TW: v2.35.0 round 1 (1 fuzzy) | 22 January 2022, 08:27:41 UTC |
| 519947b | Junio C Hamano | 22 January 2022, 00:58:30 UTC | checkout: avoid BUG() when hitting a broken repository When 9081a421 (checkout: fix "branch info" memory leaks, 2021-11-16) cleaned up existing memory leaks, we added an unrelated sanity check to ensure that a local branch is truly local and not a symref to elsewhere that dies with BUG() otherwise. This was misguided in two ways. First of all, such a tightening did not belong to a leak-fix patch. And the condition it detected was *not* a bug in our program but a problem in user data, where warning() or die() would have been more appropriate. As the condition is not fatal (the result of computing the local branch name in the code that is involved in the faulty check is only used as a textual label for the commit), let's revert the code to the original state, i.e. strip "refs/heads/" to compute the local branch name if possible, and otherwise leave it NULL. The consumer of the information in merge_working_tree() is prepared to see NULL in there and act accordingly. cf. https://bugzilla.redhat.com/show_bug.cgi?id=2042920 Reported-by: Petr Šplíchal <psplicha@redhat.com> Reported-by: Todd Zullinger <tmz@pobox.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 22 January 2022, 01:04:50 UTC |
| 8795330 | Yi-Jyun Pan | 21 January 2022, 23:06:36 UTC | l10n: zh_TW: v2.35.0 round 2 (0 untranslated) Used 1 translation from zh_CN. Thanks to zh_CN translation team! Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com> | 21 January 2022, 23:10:43 UTC |
| b3d4896 | Jordi Mas | 21 January 2022, 06:56:02 UTC | l10n: Update Catalan translation Signed-off-by: Jordi Mas <jmas@softcatala.org> | 21 January 2022, 06:56:02 UTC |
| 297ca89 | Junio C Hamano | 20 January 2022, 23:25:38 UTC | Merge branch 'js/branch-track-inherit' "git branch -h" incorrectly said "--track[=direct|inherit]", implying that "--trackinherit" is a valid option, which has been corrected. source: <3de40324bea6a1dd9bca2654721471e3809e87d8.1642538935.git.steadmon@google.com> source: <c3c26192-aee9-185a-e559-b8735139e49c@web.de> * js/branch-track-inherit: branch,checkout: fix --track documentation | 20 January 2022, 23:25:38 UTC |
| 6327f0e | René Scharfe | 20 January 2022, 12:35:54 UTC | branch,checkout: fix --track documentation Document that the accepted variants of the --track option are --track, --track=direct, and --track=inherit. The equal sign in the latter two cannot be replaced with whitespace; in general optional arguments need to be attached firmly to their option. Put "direct" consistently before "inherit", if only for the reasons that the former is the default, explained first in the documentation, and comes before the latter alphabetically. Mention both modes in the short help so that readers don't have to look them up in the full documentation. They are literal strings and thus untranslatable. PARSE_OPT_LITERAL_ARGHELP is inferred due to the pipe and parenthesis characters, so we don't have to provide that flag explicitly. Mention that -t has the same effect as --track and --track=direct. There is no way to specify inherit mode using the short option, because short options generally don't accept optional arguments. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 20 January 2022, 19:07:51 UTC |
| 159af2a | Matthias Rüster | 15 January 2022, 15:36:51 UTC | l10n: de.po: Update German translation Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com> Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com> | 20 January 2022, 17:23:36 UTC |
| ea0fca8 | Jürgen Krämer | 18 November 2021, 15:25:48 UTC | l10n: de.po: Fix translation for "'%s' is aliased to '%s'" The German translation for "'%s' is aliased to '%s'" is incorrect. It switches the order of alias name and alias definition. A better translation would be "'%s' ist ein Alias für '%s'". (Full stop removed intentionally, because the original does not use one either.) Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com> | 20 January 2022, 17:11:37 UTC |
| 7ff31e1 | Jiang Xin | 20 January 2022, 02:40:08 UTC | Merge branch 'po-id' of github.com:bagasme/git-po * 'po-id' of github.com:bagasme/git-po: l10n: po-id for 2.35 (round 2) | 20 January 2022, 02:40:08 UTC |
| 50b2d72 | Junio C Hamano | 19 January 2022, 20:48:46 UTC | Git 2.35-rc2 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 19 January 2022, 20:48:46 UTC |
| e2724c1 | Johannes Schindelin | 19 January 2022, 18:56:01 UTC | getcwd(mingw): handle the case when there is no cwd A recent upstream topic introduced checks for certain Git commands that prevent them from deleting the current working directory, introducing also a regression test that ensures that commands such as `git version` _can_ run without a current working directory. While technically not possible on Windows via the regular Win32 API, we do run the regression tests in an MSYS2 Bash which uses a POSIX emulation layer (the MSYS2/Cygwin runtime) where a really evil hack _does_ allow to delete a directory even if it is the current working directory. Therefore, Git needs to be prepared for a missing working directory, even on Windows. This issue was not noticed in upstream Git because there was no caller that tried to discover a Git directory with a deleted current working directory in the test suite. But in the microsoft/git fork, we do want to run `pre-command`/`post-command` hooks for every command, even for `git version`, which means that we make precisely such a call. The bug is not in that `pre-command`/`post-command` feature, though, but in `mingw_getcwd()` and needs to be addressed there. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 19 January 2022, 19:27:31 UTC |
| 80dabf9 | Bagas Sanjaya | 18 January 2022, 08:27:07 UTC | l10n: po-id for 2.35 (round 2) Translate following new components: * advice.c * alias.c * sequencer.c * sparse-index.c * builtin/sparse-checkout.c Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> | 19 January 2022, 10:59:41 UTC |
| 0f8f20f | Jordi Mas | 19 January 2022, 06:50:14 UTC | l10n: Update Catalan translation Signed-off-by: Jordi Mas <jmas@softcatala.org> | 19 January 2022, 06:56:01 UTC |
| af4e5f5 | Junio C Hamano | 19 January 2022, 00:02:23 UTC | Merge branch 'js/branch-track-inherit' "git branch -h" incorrectly said "--track[=direct|inherit]", implying that "--trackinherit" is a valid option, which has been corrected. * js/branch-track-inherit: branch,checkout: fix --track usage strings | 19 January 2022, 00:02:23 UTC |
| 0330edb | Junio C Hamano | 19 January 2022, 00:02:23 UTC | Merge branch 'jc/freebsd-without-c99-only-build' FreeBSD 13.0 headers have unconditional dependency on C11 language features, and adding -std=gnu99 to DEVELOPER_CFLAGS would just break the developer build. * jc/freebsd-without-c99-only-build: Makefile: FreeBSD cannot do C99-or-below build | 19 January 2022, 00:02:23 UTC |
| 15f0028 | Josh Steadmon | 18 January 2022, 20:49:46 UTC | branch,checkout: fix --track usage strings As Ævar pointed out in [1], the use of PARSE_OPT_LITERAL_ARGHELP with a list of allowed parameters is not recommended. Both git-branch and git-checkout were changed in d311566 (branch: add flags and config to inherit tracking, 2021-12-20) to use this discouraged combination for their --track flags. Fix this by removing PARSE_OPT_LITERAL_ARGHELP, and changing the arghelp to simply be "mode". Users may discover allowed values in the manual pages. [1]: https://lore.kernel.org/git/220111.86a6g3yqf9.gmgdl@evledraar.gmail.com/ Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 18 January 2022, 22:08:15 UTC |
| 2b95d94 | Junio C Hamano | 18 January 2022, 17:47:39 UTC | Makefile: FreeBSD cannot do C99-or-below build In "make DEVELOPER=YesPlease" builds, we try to help developers to catch as many potential issues as they can by using -Wall and turning compilation warnings into errors. In the same spirit, we recently started adding -std=gnu99 to their CFLAGS, so that they can notice when they accidentally used language features beyond C99. It however turns out that FreeBSD 13.0 mistakenly uses C11 extension in its system header files regardless of what __STDC_VERSION__ says, which means that the platform (unless we tweak their system headers) cannot be used for this purpose. It seems that -std=gnu99 is only added conditionally even in today's config.mak.dev, so it is fine if we dropped -std=gnu99 from there. Which means that developers on FreeBSD cannot participate in vetting use of features beyond C99, but there are developers on other platforms who will, so it's not too bad. We might want a more "fundamental" fix to make the platform capable of taking -std=gnu99, like working around the use of unconditional C11 extension in its system header files by supplying a set of "replacement" definitions in our header files. We chose not to pursue such an approach for two reasons at this point: (1) The fix belongs to the FreeBSD project, not this project, and such an upstream fix may happen hopefully in a not-too-distant future. (2) Fixing such a bug in system header files and working it around can lead to unexpected breakages (other parts of their system header files may not be expecting to see and do not work well with our "replacement" definitions). This close to the final release of this cycle, we have no time for that. Signed-off-by: Junio C Hamano <gitster@pobox.com> | 18 January 2022, 20:16:23 UTC |
| b56bd95 | Junio C Hamano | 17 January 2022, 23:15:59 UTC | Merge branch 'da/rhel7-lacks-uncompress2-and-c99' Adjust build on RHEL 7 to explicitly ask C99 support and use the fallback implementation of uncompress2 we ship. * da/rhel7-lacks-uncompress2-and-c99: build: centos/RHEL 7 ships with an older gcc and zlib | 17 January 2022, 23:15:59 UTC |
| 6bcc4e2 | Tran Ngoc Quan | 17 January 2022, 07:15:31 UTC | l10n: vi(5195t): Update for v2.35.0 round 2 Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com> | 17 January 2022, 07:15:31 UTC |
| ee27abd | Jiang Xin | 17 January 2022, 00:50:41 UTC | l10n: batch update to fix typo in branch.c In git 2.35 l10n round 1, a space between two words was missing in the message from "branch.c", and it was fixed by commit 68d924e1de (branch: missing space fix at line 313, 2022-01-11). Do a batch update for teams (bg, fr, id, sv, tr and zh_CN) that have already completed their works on l10n round 1. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> | 17 January 2022, 00:58:49 UTC |
| fe7f7ad | Jiang Xin | 17 January 2022, 00:32:09 UTC | l10n: git.pot: v2.35.0 round 2 (1 new, 1 removed) Generate po/git.pot from v2.35.0-rc1 for git v2.35.0 l10n round 2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> | 17 January 2022, 00:32:09 UTC |
| 90999dd | Jiang Xin | 17 January 2022, 00:30:45 UTC | Merge tag 'v2.35.0-rc1' Git 2.35-rc1 * tag 'v2.35.0-rc1': Git 2.35-rc1 reftable tests: avoid "int" overflow, use "uint64_t" reftable: avoid initializing structs from structs t1450-fsck: exec-bit is not needed to make loose object writable refs API: use "failure_errno", not "errno" Last minute fixes before -rc1 build: NonStop ships with an older zlib packfile: fix off-by-one error in decoding logic t/gpg: simplify test for unknown key branch: missing space fix at line 313 fmt-merge-msg: prevent use-after-free with signed tags cache.h: drop duplicate `ensure_full_index()` declaration lazyload: use correct calling conventions fetch: fix deadlock when cleaning up lockfiles in async signals | 17 January 2022, 00:30:45 UTC |
| ffb9f29 | David Aguilar | 16 January 2022, 02:05:20 UTC | build: centos/RHEL 7 ships with an older gcc and zlib GCC 4.8.5 is the default system compiler on centos7/RHEL7. This version requires -std=c99 to enable c99 support. zlib 1.2.7 on centos7/rhel7 lacks uncompress2(). Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 16 January 2022, 22:18:17 UTC |
| c8464a3 | Alexander Shopov | 15 January 2022, 22:35:45 UTC | l10n: bg.po: Updated Bulgarian translation (5195t) Signed-off-by: Alexander Shopov <ash@kambanaria.org> | 16 January 2022, 09:51:37 UTC |
| df3c41a | Junio C Hamano | 14 January 2022, 23:26:53 UTC | Git 2.35-rc1 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 14 January 2022, 23:26:53 UTC |
| 36b6571 | Junio C Hamano | 14 January 2022, 23:25:15 UTC | Merge branch 'js/t1450-making-it-writable-does-not-need-full-posixperm' Test fix. * js/t1450-making-it-writable-does-not-need-full-posixperm: t1450-fsck: exec-bit is not needed to make loose object writable | 14 January 2022, 23:25:15 UTC |
| 9a329bd | Junio C Hamano | 14 January 2022, 23:25:15 UTC | Merge branch 'ab/reftable-build-fixes' A few portability tweaks. * ab/reftable-build-fixes: reftable tests: avoid "int" overflow, use "uint64_t" reftable: avoid initializing structs from structs | 14 January 2022, 23:25:15 UTC |
| 31e3912 | Junio C Hamano | 14 January 2022, 23:25:14 UTC | Merge branch 'ab/refs-errno-cleanup' A brown-paper-bag fix on top of a topic that was merged during this cycle. * ab/refs-errno-cleanup: refs API: use "failure_errno", not "errno" | 14 January 2022, 23:25:15 UTC |
| 22d2f70 | Ævar Arnfjörð Bjarmason | 11 January 2022, 16:40:23 UTC | reftable tests: avoid "int" overflow, use "uint64_t" Change code added in 1ae2b8cda84 (reftable: add merged table view, 2021-10-07) to consistently use the "uint64_t" type. These "min" and "max" variables get passed in the body of this function to a function whose prototype is: [...] reftable_writer_set_limits([...], uint64_t min, uint64_t max This avoids the following warning on SunCC 12.5 on gcc211.fsffrance.org: "reftable/merged_test.c", line 27: warning: initializer does not fit or is out of range: 0xffffffff Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 January 2022, 21:39:09 UTC |
| f2b2551 | Han-Wen Nienhuys | 13 January 2022, 16:55:34 UTC | reftable: avoid initializing structs from structs Apparently, the IBM xlc compiler doesn't like this. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 January 2022, 21:36:34 UTC |
| 5906910 | Johannes Sixt | 13 January 2022, 20:28:45 UTC | t1450-fsck: exec-bit is not needed to make loose object writable A test case wants to append stuff to a loose object file to ensure that this kind of corruption is detected. To make a read-only loose object file writable with chmod, it is not necessary to also make it executable. Replace the bitmask 755 with the instruction +w to request only the write bit and to also heed the umask. And get rid of a POSIXPERM prerequisite, which is unnecessary for the test. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 January 2022, 20:36:12 UTC |
| cac15b3 | Ævar Arnfjörð Bjarmason | 12 January 2022, 12:36:46 UTC | refs API: use "failure_errno", not "errno" Fix a logic error in refs_resolve_ref_unsafe() introduced in a recent series of mine to abstract the refs API away from errno. See 96f6623ada0 (Merge branch 'ab/refs-errno-cleanup', 2021-11-29)for that series. In that series introduction of "failure_errno" to refs_resolve_ref_unsafe came in ef18119dec8 (refs API: add a version of refs_resolve_ref_unsafe() with "errno", 2021-10-16). There we'd set "errno = 0" immediately before refs_read_raw_ref(), and then set "failure_errno" to "errno" if errno was non-zero afterwards. Then in the next commit 8b72fea7e91 (refs API: make refs_read_raw_ref() not set errno, 2021-10-16) we started expecting "refs_read_raw_ref()" to set "failure_errno". It would do that if refs_read_raw_ref() failed, but it wouldn't be the same errno. So we might set the "errno" here to any arbitrary bad value, and end up e.g. returning NULL when we meant to return the refname from refs_resolve_ref_unsafe(), or the other way around. Instrumenting this code will reveal cases where refs_read_raw_ref() will fail, and "errno" and "failure_errno" will be set to different values. In practice I haven't found a case where this scary bug changed anything in practice. The reason for that is that we'll not care about the actual value of "errno" here per-se, but only whether: 1. We have an errno 2. If it's one of ENOENT, EISDIR or ENOTDIR. See the adjacent code added in a1c1d8170db (refs_resolve_ref_unsafe: handle d/f conflicts for writes, 2017-10-06) I.e. if we clobber "failure_errno" with "errno", but it happened to be one of those three, and we'll clobber it with another one of the three we were OK. Perhaps there are cases where the difference ended up mattering, but I haven't found them. Instrumenting the test suite to fail if "errno" and "failure_errno" are different shows a lot of failures, checking if they're different *and* one is but not the other is outside that list of three "errno" values yields no failures. But let's fix the obvious bug. We should just stop paying attention to "errno" in refs_resolve_ref_unsafe(). In addition let's change the partial resetting of "errno" in files_read_raw_ref() to happen just before the "return", to ensure that any such bug will be more easily spotted in the future. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 January 2022, 18:53:54 UTC |
| 65387fd | Fangyi Zhou | 11 January 2022, 16:42:06 UTC | l10n: zh_CN: v2.35.0 round 1 - Translate new messages - Translate the word 'cone' instead of leaving it verbatim (in the context of sparse checkout) - Make translations of 'failed to' consistent Signed-off-by: Fangyi Zhou <me@fangyi.io> Reviewed-by: Teng Long <dyroneteng@gmail.com> Reviewed-by: 依云 <lilydjwg@gmail.com> Reviewed-by: Jiang Xin <worldhello.net@gmail.com> | 13 January 2022, 13:15:04 UTC |
| 14a38ad | Jiang Xin | 13 January 2022, 01:11:17 UTC | Merge branch 'fr_2.35.0_rnd1' of github.com:jnavila/git * 'fr_2.35.0_rnd1' of github.com:jnavila/git: l10n: fr: v2.35.0 round 1 | 13 January 2022, 01:11:17 UTC |
| 1ffcbaa | Junio C Hamano | 13 January 2022, 00:27:08 UTC | Last minute fixes before -rc1 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 13 January 2022, 00:27:08 UTC |
| 12f82b0 | Junio C Hamano | 12 January 2022, 23:11:43 UTC | Merge branch 'ps/lockfile-cleanup-fix' Some lockfile code called free() in signal-death code path, which has been corrected. * ps/lockfile-cleanup-fix: fetch: fix deadlock when cleaning up lockfiles in async signals | 12 January 2022, 23:11:43 UTC |
| 453cef7 | Junio C Hamano | 12 January 2022, 23:11:43 UTC | Merge branch 'ma/header-dup-cleanup' Code clean-up. * ma/header-dup-cleanup: cache.h: drop duplicate `ensure_full_index()` declaration | 12 January 2022, 23:11:43 UTC |
| 83ca082 | Junio C Hamano | 12 January 2022, 23:11:42 UTC | Merge branch 'fs/gpg-unknown-key-test-fix' Test simplification. * fs/gpg-unknown-key-test-fix: t/gpg: simplify test for unknown key | 12 January 2022, 23:11:42 UTC |
| 2a72807 | Junio C Hamano | 12 January 2022, 23:11:41 UTC | Merge branch 'ak/protect-any-current-branch' * ak/protect-any-current-branch: branch: missing space fix at line 313 | 12 January 2022, 23:11:41 UTC |
| c9c0828 | Junio C Hamano | 12 January 2022, 23:11:41 UTC | Merge branch 'jt/pack-header-lshift-overflow' * jt/pack-header-lshift-overflow: packfile: fix off-by-one error in decoding logic | 12 January 2022, 23:11:41 UTC |
| 4e2e2a4 | Junio C Hamano | 12 January 2022, 23:11:41 UTC | Merge branch 'rb/nonstop-lacks-uncompress2' * rb/nonstop-lacks-uncompress2: build: NonStop ships with an older zlib | 12 January 2022, 23:11:41 UTC |
| a4510f8 | Junio C Hamano | 12 January 2022, 23:11:41 UTC | Merge branch 'ma/windows-dynload-fix' Fix calling dynamically loaded functions on Windows. * ma/windows-dynload-fix: lazyload: use correct calling conventions | 12 January 2022, 23:11:41 UTC |
| cde28af | Junio C Hamano | 12 January 2022, 23:11:41 UTC | Merge branch 'fs/ssh-signing-key-lifetime' "git merge $signed_tag" started to drop the tag message from the default merge message it uses by accident, which has been corrected. * fs/ssh-signing-key-lifetime: fmt-merge-msg: prevent use-after-free with signed tags | 12 January 2022, 23:11:41 UTC |
| 68d1da4 | Randall S. Becker | 11 January 2022, 03:51:39 UTC | build: NonStop ships with an older zlib Notably, it lacks uncompress2(); use the fallback we ship in our tree instead. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 January 2022, 20:17:29 UTC |
| a5c97b0 | Junio C Hamano | 12 January 2022, 20:11:42 UTC | packfile: fix off-by-one error in decoding logic shift count being exactly at 7-bit smaller than the long is OK; on 32-bit architecture, shift count starts at 4 and goes through 11, 18 and 25, at which point the guard triggers one iteration too early. Reported-by: Marc Strapetz <marc.strapetz@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 January 2022, 20:14:49 UTC |
| e1e1de0 | Jean-Noël Avila | 12 January 2022, 20:14:45 UTC | l10n: fr: v2.35.0 round 1 Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> | 12 January 2022, 20:14:45 UTC |
| 0517f59 | Fabian Stelzer | 12 January 2022, 12:07:57 UTC | t/gpg: simplify test for unknown key To test for a key that is completely unknown to the keyring we need one to sign the commit with. This was done by generating a new key and not add it into the keyring. To avoid the key generation overhead and problems where GPG did hang in CI during it, switch GNUPGHOME to the empty $GNUPGHOME_NOT_USED instead, therefore making all used keys unknown for this single `verify-commit` call. Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Fabian Stelzer <fs@gigacodes.de> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 January 2022, 19:21:22 UTC |
| 68d924e | Bagas Sanjaya | 11 January 2022, 12:36:27 UTC | branch: missing space fix at line 313 The message introduced by commit 593a2a5d06 (branch: protect branches checked out in all worktrees, 2021-12-01) is missing a space in the first line, add it. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 January 2022, 18:52:52 UTC |
| cb57f25 | Yi-Jyun Pan | 12 January 2022, 17:10:46 UTC | l10n: zh_TW: v2.35.0 round 1 (1 fuzzy) Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com> | 12 January 2022, 17:10:46 UTC |
| 4b1fd48 | Bagas Sanjaya | 11 January 2022, 12:21:51 UTC | l10n: po-id for 2.35 (round 1) Update following components: * apply.c * branch.c * builtin/add.c * builtin/am.c * builtin/fetch.c * builtin/ls-files.c * builtin/stash.c Translate following new components: * archive-tar.c * archive-zip.c Also clean up obsolete translations. Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> | 12 January 2022, 11:16:47 UTC |
| 38ad274 | Jiang Xin | 12 January 2022, 05:46:21 UTC | Merge branch 'master' of github.com:nafmo/git-l10n-sv * 'master' of github.com:nafmo/git-l10n-sv: l10n: sv.po: Update Swedish translation (5196t0f0u) l10n: sv.po: Fix typo | 12 January 2022, 05:46:21 UTC |
