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 |
94f6e3e | Johannes Schindelin | 12 February 2021, 14:51:13 UTC | Git 2.30.2 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:51:13 UTC |
e4e6808 | Johannes Schindelin | 12 February 2021, 14:51:12 UTC | Sync with 2.29.3 * maint-2.29: Git 2.29.3 Git 2.28.1 Git 2.27.1 Git 2.26.3 Git 2.25.5 Git 2.24.4 Git 2.23.4 Git 2.22.5 Git 2.21.4 Git 2.20.5 Git 2.19.6 Git 2.18.5 Git 2.17.6 unpack_trees(): start with a fresh lstat cache run-command: invalidate lstat cache after a command finished checkout: fix bug that makes checkout follow symlinks in leading path | 12 February 2021, 14:51:12 UTC |
0628636 | Johannes Schindelin | 12 February 2021, 14:50:15 UTC | Git 2.29.3 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:50:15 UTC |
d7bdabe | Johannes Schindelin | 12 February 2021, 14:50:14 UTC | Sync with 2.28.1 * maint-2.28: Git 2.28.1 Git 2.27.1 Git 2.26.3 Git 2.25.5 Git 2.24.4 Git 2.23.4 Git 2.22.5 Git 2.21.4 Git 2.20.5 Git 2.19.6 Git 2.18.5 Git 2.17.6 unpack_trees(): start with a fresh lstat cache run-command: invalidate lstat cache after a command finished checkout: fix bug that makes checkout follow symlinks in leading path | 12 February 2021, 14:50:14 UTC |
e4f4299 | Johannes Schindelin | 12 February 2021, 14:50:10 UTC | Git 2.28.1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:50:10 UTC |
3f01e56 | Johannes Schindelin | 12 February 2021, 14:50:09 UTC | Sync with 2.27.1 * maint-2.27: Git 2.27.1 Git 2.26.3 Git 2.25.5 Git 2.24.4 Git 2.23.4 Git 2.22.5 Git 2.21.4 Git 2.20.5 Git 2.19.6 Git 2.18.5 Git 2.17.6 unpack_trees(): start with a fresh lstat cache run-command: invalidate lstat cache after a command finished checkout: fix bug that makes checkout follow symlinks in leading path | 12 February 2021, 14:50:09 UTC |
6ff7f46 | Johannes Schindelin | 12 February 2021, 14:50:05 UTC | Git 2.27.1 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:50:05 UTC |
2d1142a | Johannes Schindelin | 12 February 2021, 14:50:04 UTC | Sync with 2.26.3 * maint-2.26: Git 2.26.3 Git 2.25.5 Git 2.24.4 Git 2.23.4 Git 2.22.5 Git 2.21.4 Git 2.20.5 Git 2.19.6 Git 2.18.5 Git 2.17.6 unpack_trees(): start with a fresh lstat cache run-command: invalidate lstat cache after a command finished checkout: fix bug that makes checkout follow symlinks in leading path | 12 February 2021, 14:50:04 UTC |
a79fd20 | Johannes Schindelin | 12 February 2021, 14:50:00 UTC | Git 2.26.3 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:50:00 UTC |
8f80393 | Johannes Schindelin | 12 February 2021, 14:49:59 UTC | Sync with 2.25.5 * maint-2.25: Git 2.25.5 Git 2.24.4 Git 2.23.4 Git 2.22.5 Git 2.21.4 Git 2.20.5 Git 2.19.6 Git 2.18.5 Git 2.17.6 unpack_trees(): start with a fresh lstat cache run-command: invalidate lstat cache after a command finished checkout: fix bug that makes checkout follow symlinks in leading path | 12 February 2021, 14:49:59 UTC |
42ce4c7 | Johannes Schindelin | 12 February 2021, 14:49:55 UTC | Git 2.25.5 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:49:55 UTC |
97d1dcb | Johannes Schindelin | 12 February 2021, 14:49:55 UTC | Sync with 2.24.4 * maint-2.24: Git 2.24.4 Git 2.23.4 Git 2.22.5 Git 2.21.4 Git 2.20.5 Git 2.19.6 Git 2.18.5 Git 2.17.6 unpack_trees(): start with a fresh lstat cache run-command: invalidate lstat cache after a command finished checkout: fix bug that makes checkout follow symlinks in leading path | 12 February 2021, 14:49:55 UTC |
06214d1 | Johannes Schindelin | 12 February 2021, 14:49:50 UTC | Git 2.24.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:49:50 UTC |
92ac04b | Johannes Schindelin | 12 February 2021, 14:49:50 UTC | Sync with 2.23.4 * maint-2.23: Git 2.23.4 Git 2.22.5 Git 2.21.4 Git 2.20.5 Git 2.19.6 Git 2.18.5 Git 2.17.6 unpack_trees(): start with a fresh lstat cache run-command: invalidate lstat cache after a command finished checkout: fix bug that makes checkout follow symlinks in leading path | 12 February 2021, 14:49:50 UTC |
d60b6a9 | Johannes Schindelin | 12 February 2021, 14:49:46 UTC | Git 2.23.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:49:46 UTC |
4bd06fd | Johannes Schindelin | 12 February 2021, 14:49:45 UTC | Sync with 2.22.5 * maint-2.22: Git 2.22.5 Git 2.21.4 Git 2.20.5 Git 2.19.6 Git 2.18.5 Git 2.17.6 unpack_trees(): start with a fresh lstat cache run-command: invalidate lstat cache after a command finished checkout: fix bug that makes checkout follow symlinks in leading path | 12 February 2021, 14:49:45 UTC |
c753e2a | Johannes Schindelin | 12 February 2021, 14:49:41 UTC | Git 2.22.5 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:49:41 UTC |
bcf08f3 | Johannes Schindelin | 12 February 2021, 14:49:41 UTC | Sync with 2.21.4 * maint-2.21: Git 2.21.4 Git 2.20.5 Git 2.19.6 Git 2.18.5 Git 2.17.6 unpack_trees(): start with a fresh lstat cache run-command: invalidate lstat cache after a command finished checkout: fix bug that makes checkout follow symlinks in leading path | 12 February 2021, 14:49:41 UTC |
c735d74 | Johannes Schindelin | 12 February 2021, 14:49:36 UTC | Git 2.21.4 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:49:36 UTC |
b1726b1 | Johannes Schindelin | 12 February 2021, 14:49:35 UTC | Sync with 2.20.5 * maint-2.20: Git 2.20.5 Git 2.19.6 Git 2.18.5 Git 2.17.6 unpack_trees(): start with a fresh lstat cache run-command: invalidate lstat cache after a command finished checkout: fix bug that makes checkout follow symlinks in leading path | 12 February 2021, 14:49:35 UTC |
8b1a5f3 | Johannes Schindelin | 12 February 2021, 14:49:17 UTC | Git 2.20.5 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:49:17 UTC |
8049638 | Johannes Schindelin | 12 February 2021, 14:49:17 UTC | Sync with 2.19.6 * maint-2.19: Git 2.19.6 Git 2.18.5 Git 2.17.6 unpack_trees(): start with a fresh lstat cache run-command: invalidate lstat cache after a command finished checkout: fix bug that makes checkout follow symlinks in leading path | 12 February 2021, 14:49:17 UTC |
9fb2a1f | Johannes Schindelin | 12 February 2021, 14:47:48 UTC | Git 2.19.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:47:48 UTC |
fb049fd | Johannes Schindelin | 12 February 2021, 14:47:47 UTC | Sync with 2.18.5 * maint-2.18: Git 2.18.5 Git 2.17.6 unpack_trees(): start with a fresh lstat cache run-command: invalidate lstat cache after a command finished checkout: fix bug that makes checkout follow symlinks in leading path | 12 February 2021, 14:47:47 UTC |
6eed462 | Johannes Schindelin | 12 February 2021, 14:47:43 UTC | Git 2.18.5 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:47:43 UTC |
9b77cec | Johannes Schindelin | 12 February 2021, 14:47:42 UTC | Sync with 2.17.6 * maint-2.17: Git 2.17.6 unpack_trees(): start with a fresh lstat cache run-command: invalidate lstat cache after a command finished checkout: fix bug that makes checkout follow symlinks in leading path | 12 February 2021, 14:47:42 UTC |
6b82d3e | Johannes Schindelin | 29 January 2021, 18:13:11 UTC | Git 2.17.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:47:02 UTC |
22539ec | Matheus Tavares | 02 February 2021, 21:37:10 UTC | unpack_trees(): start with a fresh lstat cache We really want to avoid relying on stale information. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:47:02 UTC |
0d58fef | Johannes Schindelin | 02 February 2021, 21:09:52 UTC | run-command: invalidate lstat cache after a command finished In the previous commit, we intercepted calls to `rmdir()` to invalidate the lstat cache in the successful case, so that the lstat cache could not have the idea that a directory exists where there is none. The same situation can arise, of course, when a separate process is spawned (most notably, this is the case in `submodule_move_head()`). Obviously, we cannot know whether a directory was removed in that process, therefore we must invalidate the lstat cache afterwards. Note: in contrast to `lstat_cache_aware_rmdir()`, we invalidate the lstat cache even in case of an error: the process might have removed a directory and still have failed afterwards. Co-authored-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> | 12 February 2021, 14:47:02 UTC |
684dd4c | Matheus Tavares | 10 December 2020, 13:27:55 UTC | checkout: fix bug that makes checkout follow symlinks in leading path Before checking out a file, we have to confirm that all of its leading components are real existing directories. And to reduce the number of lstat() calls in this process, we cache the last leading path known to contain only directories. However, when a path collision occurs (e.g. when checking out case-sensitive files in case-insensitive file systems), a cached path might have its file type changed on disk, leaving the cache on an invalid state. Normally, this doesn't bring any bad consequences as we usually check out files in index order, and therefore, by the time the cached path becomes outdated, we no longer need it anyway (because all files in that directory would have already been written). But, there are some users of the checkout machinery that do not always follow the index order. In particular: checkout-index writes the paths in the same order that they appear on the CLI (or stdin); and the delayed checkout feature -- used when a long-running filter process replies with "status=delayed" -- postpones the checkout of some entries, thus modifying the checkout order. When we have to check out an out-of-order entry and the lstat() cache is invalid (due to a previous path collision), checkout_entry() may end up using the invalid data and thrusting that the leading components are real directories when, in reality, they are not. In the best case scenario, where the directory was replaced by a regular file, the user will get an error: "fatal: unable to create file 'foo/bar': Not a directory". But if the directory was replaced by a symlink, checkout could actually end up following the symlink and writing the file at a wrong place, even outside the repository. Since delayed checkout is affected by this bug, it could be used by an attacker to write arbitrary files during the clone of a maliciously crafted repository. Some candidate solutions considered were to disable the lstat() cache during unordered checkouts or sort the entries before passing them to the checkout machinery. But both ideas include some performance penalty and they don't future-proof the code against new unordered use cases. Instead, we now manually reset the lstat cache whenever we successfully remove a directory. Note: We are not even checking whether the directory was the same as the lstat cache points to because we might face a scenario where the paths refer to the same location but differ due to case folding, precomposed UTF-8 issues, or the presence of `..` components in the path. Two regression tests, with case-collisions and utf8-collisions, are also added for both checkout-index and delayed checkout. Note: to make the previously mentioned clone attack unfeasible, it would be sufficient to reset the lstat cache only after the remove_subtree() call inside checkout_entry(). This is the place where we would remove a directory whose path collides with the path of another entry that we are currently trying to check out (possibly a symlink). However, in the interest of a thorough fix that does not leave Git open to similar-but-not-identical attack vectors, we decided to intercept all `rmdir()` calls in one fell swoop. This addresses CVE-2021-21300. Co-authored-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> | 12 February 2021, 14:47:02 UTC |
59ec224 | Junio C Hamano | 11 February 2021, 21:57:36 UTC | Merge branch 'tb/ci-run-cocci-with-18.04' into maint * tb/ci-run-cocci-with-18.04: .github/workflows/main.yml: run static-analysis on bionic | 11 February 2021, 21:57:36 UTC |
d051ed7 | Taylor Blau | 08 February 2021, 21:22:34 UTC | .github/workflows/main.yml: run static-analysis on bionic GitHub Actions is transitioning workflow steps that run on 'ubuntu-latest' from 18.04 to 20.04 [1]. This works fine in all steps except the static-analysis one, since Coccinelle isn't available on Ubuntu focal (it is only available in the universe suite). Until Coccinelle can be installed from 20.04's main suite, pin the static-analysis build to run on 18.04, where it can be installed by default. [1]: https://github.com/actions/virtual-environments/issues/1816 Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 08 February 2021, 22:38:07 UTC |
773e25a | Junio C Hamano | 08 February 2021, 22:05:35 UTC | Git 2.30.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 08 February 2021, 22:05:55 UTC |
dadf9e5 | Junio C Hamano | 08 February 2021, 22:05:55 UTC | Merge branch 'pb/ci-matrix-wo-shortcut' into maint Our setting of GitHub CI test jobs were a bit too eager to give up once there is even one failure found. Tweak the knob to allow other jobs keep running even when we see a failure, so that we can find more failures in a single run. * pb/ci-matrix-wo-shortcut: ci: do not cancel all jobs of a matrix if one fails | 08 February 2021, 22:05:55 UTC |
f20aeed | Junio C Hamano | 08 February 2021, 22:05:55 UTC | Merge branch 'pb/blame-funcname-range-userdiff' into maint Test fix. * pb/blame-funcname-range-userdiff: annotate-tests: quote variable expansions containing path names | 08 February 2021, 22:05:55 UTC |
6a7bf0d | Junio C Hamano | 08 February 2021, 22:05:55 UTC | Merge branch 'jk/p5303-sed-portability-fix' into maint A perf script was made more portable. * jk/p5303-sed-portability-fix: p5303: avoid sed GNU-ism | 08 February 2021, 22:05:55 UTC |
f2d156d | Junio C Hamano | 08 February 2021, 22:05:55 UTC | Merge branch 'ab/branch-sort' into maint The implementation of "git branch --sort" wrt the detached HEAD display has always been hacky, which has been cleaned up. * ab/branch-sort: branch: show "HEAD detached" first under reverse sort branch: sort detached HEAD based on a flag ref-filter: move ref_sorting flags to a bitfield ref-filter: move "cmp_fn" assignment into "else if" arm ref-filter: add braces to if/else if/else chain branch tests: add to --sort tests branch: change "--local" to "--list" in comment | 08 February 2021, 22:05:55 UTC |
171675a | Junio C Hamano | 08 February 2021, 22:05:54 UTC | Merge branch 'ma/more-opaque-lock-file' into maint Code clean-up. * ma/more-opaque-lock-file: read-cache: try not to peek into `struct {lock_,temp}file` refs/files-backend: don't peek into `struct lock_file` midx: don't peek into `struct lock_file` commit-graph: don't peek into `struct lock_file` builtin/gc: don't peek into `struct lock_file` | 08 February 2021, 22:05:55 UTC |
6a20b9b | Junio C Hamano | 08 February 2021, 22:05:54 UTC | Merge branch 'dl/p4-encode-after-kw-expansion' into maint Text encoding fix for "git p4". * dl/p4-encode-after-kw-expansion: git-p4: fix syncing file types with pattern | 08 February 2021, 22:05:54 UTC |
f0e3c7f | Junio C Hamano | 08 February 2021, 22:05:54 UTC | Merge branch 'ar/t6016-modernise' into maint Test update. * ar/t6016-modernise: t6016: move to lib-log-graph.sh framework | 08 February 2021, 22:05:54 UTC |
3e52ab2 | Junio C Hamano | 08 February 2021, 22:05:54 UTC | Merge branch 'zh/arg-help-format' into maint Clean up option descriptions in "git cmd --help". * zh/arg-help-format: builtin/*: update usage format parse-options: format argh like error messages | 08 February 2021, 22:05:54 UTC |
71e83b2 | Junio C Hamano | 08 February 2021, 22:05:53 UTC | Merge branch 'ma/doc-pack-format-varint-for-sizes' into maint Doc update. * ma/doc-pack-format-varint-for-sizes: pack-format.txt: document sizes at start of delta data | 08 February 2021, 22:05:54 UTC |
5731e40 | Junio C Hamano | 08 February 2021, 22:05:53 UTC | Merge branch 'ma/t1300-cleanup' into maint Code clean-up. * ma/t1300-cleanup: t1300: don't needlessly work with `core.foo` configs t1300: remove duplicate test for `--file no-such-file` t1300: remove duplicate test for `--file ../foo` | 08 February 2021, 22:05:53 UTC |
7734136 | Junio C Hamano | 08 February 2021, 22:05:53 UTC | Merge branch 'fc/t6030-bisect-reset-removes-auxiliary-files' into maint A 3-year old test that was not testing anything useful has been corrected. * fc/t6030-bisect-reset-removes-auxiliary-files: test: bisect-porcelain: fix location of files | 08 February 2021, 22:05:53 UTC |
d592233 | Junio C Hamano | 06 February 2021, 00:30:42 UTC | Prepare for 2.30.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> | 06 February 2021, 00:31:28 UTC |
b778c1e | Junio C Hamano | 06 February 2021, 00:31:28 UTC | Merge branch 'js/skip-dashed-built-ins-from-config-mak' into maint Build fix. * js/skip-dashed-built-ins-from-config-mak: SKIP_DASHED_BUILT_INS: respect `config.mak` | 06 February 2021, 00:31:28 UTC |
93da966 | Junio C Hamano | 06 February 2021, 00:31:28 UTC | Merge branch 'jt/packfile-as-uri-doc' into maint Doc fix for packfile URI feature. * jt/packfile-as-uri-doc: Doc: clarify contents of packfile sent as URI | 06 February 2021, 00:31:28 UTC |
53ac9ac | Junio C Hamano | 06 February 2021, 00:31:28 UTC | Merge branch 'ab/fsck-doc-fix' into maint Documentation for "git fsck" lost stale bits that has become incorrect. * ab/fsck-doc-fix: fsck doc: remove ancient out-of-date diagnostics | 06 February 2021, 00:31:28 UTC |
2d43667 | Junio C Hamano | 06 February 2021, 00:31:27 UTC | Merge branch 'jk/log-cherry-pick-duplicate-patches' into maint When more than one commit with the same patch ID appears on one side, "git log --cherry-pick A...B" did not exclude them all when a commit with the same patch ID appears on the other side. Now it does. * jk/log-cherry-pick-duplicate-patches: patch-ids: handle duplicate hashmap entries | 06 February 2021, 00:31:28 UTC |
635ff67 | Junio C Hamano | 06 February 2021, 00:31:27 UTC | Merge branch 'jk/forbid-lf-in-git-url' into maint Newline characters in the host and path part of git:// URL are now forbidden. * jk/forbid-lf-in-git-url: fsck: reject .gitmodules git:// urls with newlines git_connect_git(): forbid newlines in host and path | 06 February 2021, 00:31:27 UTC |
8ff9ec4 | Junio C Hamano | 06 February 2021, 00:31:26 UTC | Merge branch 'jc/macos-install-dependencies-fix' into maint Fix for procedure to building CI test environment for mac. * jc/macos-install-dependencies-fix: ci/install-depends: attempt to fix "brew cask" stuff | 06 February 2021, 00:31:26 UTC |
9d36b1e | Junio C Hamano | 06 February 2021, 00:31:26 UTC | Merge branch 'tb/local-clone-race-doc' into maint Doc update. * tb/local-clone-race-doc: Documentation/git-clone.txt: document race with --local | 06 February 2021, 00:31:26 UTC |
4f985d5 | Junio C Hamano | 06 February 2021, 00:31:26 UTC | Merge branch 'bc/doc-status-short' into maint Doc update. * bc/doc-status-short: docs: rephrase and clarify the git status --short format | 06 February 2021, 00:31:26 UTC |
dfbdf8a | Junio C Hamano | 06 February 2021, 00:31:26 UTC | Merge branch 'ab/gettext-charset-comment-fix' into maint Comments update. * ab/gettext-charset-comment-fix: gettext.c: remove/reword a mostly-useless comment Makefile: remove a warning about old GETTEXT_POISON flag | 06 February 2021, 00:31:26 UTC |
7121735 | Junio C Hamano | 06 February 2021, 00:31:25 UTC | Merge branch 'ug/doc-lose-dircache' into maint Doc update. * ug/doc-lose-dircache: doc: remove "directory cache" from man pages | 06 February 2021, 00:31:26 UTC |
40a2eed | Junio C Hamano | 06 February 2021, 00:31:25 UTC | Merge branch 'ad/t4129-setfacl-target-fix' into maint Test fix. * ad/t4129-setfacl-target-fix: t4129: fix setfacl-related permissions failure | 06 February 2021, 00:31:25 UTC |
13f6bea | Junio C Hamano | 06 February 2021, 00:31:25 UTC | Merge branch 'jk/t5516-deflake' into maint Test fix. * jk/t5516-deflake: t5516: loosen "not our ref" error check | 06 February 2021, 00:31:25 UTC |
c8af1f4 | Junio C Hamano | 06 February 2021, 00:31:25 UTC | Merge branch 'vv/send-email-with-less-secure-apps-access' into maint Doc update. * vv/send-email-with-less-secure-apps-access: git-send-email.txt: mention less secure app access with Gmail | 06 February 2021, 00:31:25 UTC |
64971f0 | Junio C Hamano | 06 February 2021, 00:31:24 UTC | Merge branch 'pb/mergetool-tool-help-fix' into maint Fix 2.29 regression where "git mergetool --tool-help" fails to list all the available tools. * pb/mergetool-tool-help-fix: mergetool--lib: fix '--tool-help' to correctly show available tools | 06 February 2021, 00:31:24 UTC |
897d28b | Junio C Hamano | 06 February 2021, 00:31:23 UTC | Merge branch 'ds/for-each-repo-noopfix' into maint "git for-each-repo --config=<var> <cmd>" should not run <cmd> for any repository when the configuration variable <var> is not defined even once. * ds/for-each-repo-noopfix: for-each-repo: do nothing on empty config | 06 February 2021, 00:31:23 UTC |
4fc7b22 | Junio C Hamano | 06 February 2021, 00:31:23 UTC | Merge branch 'jc/sign-off' into maint Doc update. * jc/sign-off: SubmittingPatches: tighten wording on "sign-off" procedure | 06 February 2021, 00:31:23 UTC |
801e896 | Junio C Hamano | 06 February 2021, 00:31:22 UTC | Merge branch 'mt/t4129-with-setgid-dir' into maint Some tests expect that "ls -l" output has either '-' or 'x' for group executable bit, but setgid bit can be inherited from parent directory and make these fields 'S' or 's' instead, causing test failures. * mt/t4129-with-setgid-dir: t4129: don't fail if setgid is set in the test directory | 06 February 2021, 00:31:23 UTC |
a4031f6 | Junio C Hamano | 06 February 2021, 00:31:22 UTC | Merge branch 'en/stash-apply-sparse-checkout' into maint "git stash" did not work well in a sparsely checked out working tree. * en/stash-apply-sparse-checkout: stash: fix stash application in sparse-checkouts stash: remove unnecessary process forking t7012: add a testcase demonstrating stash apply bugs in sparse checkouts | 06 February 2021, 00:31:22 UTC |
e93f5c6 | Junio C Hamano | 06 February 2021, 00:31:22 UTC | Merge branch 'nk/perf-fsmonitor-cleanup' into maint Test fix. * nk/perf-fsmonitor-cleanup: p7519: allow running without watchman prereq | 06 February 2021, 00:31:22 UTC |
a08832f | Junio C Hamano | 06 February 2021, 00:31:22 UTC | Merge branch 'rs/rebase-commit-validation' into maint Diagnose command line error of "git rebase" early. * rs/rebase-commit-validation: rebase: verify commit parameter | 06 February 2021, 00:31:22 UTC |
9536d1b | Junio C Hamano | 06 February 2021, 00:31:21 UTC | Merge branch 'pb/doc-modules-git-work-tree-typofix' into maint Doc fix. * pb/doc-modules-git-work-tree-typofix: gitmodules.txt: fix 'GIT_WORK_TREE' variable name | 06 February 2021, 00:31:21 UTC |
9874ff5 | Junio C Hamano | 06 February 2021, 00:31:21 UTC | Merge branch 'ta/doc-typofix' into maint Doc fix. * ta/doc-typofix: doc: fix some typos | 06 February 2021, 00:31:21 UTC |
42df89b | Junio C Hamano | 06 February 2021, 00:31:20 UTC | Merge branch 'pk/subsub-fetch-fix-take-2' into maint "git fetch --recurse-submodules" fix (second attempt). * pk/subsub-fetch-fix-take-2: submodules: fix of regression on fetching of non-init subsub-repo | 06 February 2021, 00:31:21 UTC |
6eaf624 | Johannes Sixt | 30 January 2021, 16:22:25 UTC | annotate-tests: quote variable expansions containing path names The test case added by 9466e3809d ("blame: enable funcname blaming with userdiff driver", 2020-11-01) forgot to quote variable expansions. This causes failures when the current directory contains blanks. One variable that the test case introduces will not have IFS characters and could remain without quotes, but let's quote all expansions for consistency, not just the one that has the path name. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 30 January 2021, 23:15:06 UTC |
f08b6c5 | Jeff King | 29 January 2021, 20:04:08 UTC | p5303: avoid sed GNU-ism Using "1~5" isn't portable. Nobody seems to have noticed, since perhaps people don't tend to run the perf suite on more exotic platforms. Still, it's better to set a good example. We can use: perl -ne 'print if $. % 5 == 1' instead. But we can further observe that perl does a good job of the other parts of this pipeline, and fold the whole thing together. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 29 January 2021, 23:13:54 UTC |
2b0e14f | Philippe Blain | 28 January 2021, 04:06:08 UTC | ci: do not cancel all jobs of a matrix if one fails The CI/PR GitHub Actions workflow uses the 'matrix' strategy for the "windows-test", "vs-test", "regular" and "dockerized" jobs. The default behaviour of GitHub Actions is to cancel all in-progress jobs in a matrix if one of the job of the matrix fails [1]. This is not ideal as a failure early in a job, like during installation of the build/test dependencies on a specific platform, leads to the cancellation of all other jobs in the matrix. Set the 'fail-fast' variable to 'false' for all four matrix jobs in the workflow. [1] https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 28 January 2021, 06:09:42 UTC |
4a5ec7d | Johannes Schindelin | 21 January 2021, 13:09:45 UTC | SKIP_DASHED_BUILT_INS: respect `config.mak` When `SKIP_DASHED_BUILT_INS` is specified in `config.mak`, the dashed form of the built-ins was still generated. By moving the `SKIP_DASHED_BUILT_INS` handling after `config.mak` was read, this can be avoided. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 21 January 2021, 22:59:55 UTC |
28cc00a | Ævar Arnfjörð Bjarmason | 16 January 2021, 17:15:00 UTC | fsck doc: remove ancient out-of-date diagnostics Remove diagnostics that haven't been emitted by "fsck" or its predecessors for around 15 years. This documentation was added in c64b9b88605 (Reference documentation for the core git commands., 2005-05-05), but was out-of-date quickly after that. Notes on individual diagnostics: - "expect dangling commits": Added in bcee6fd8e71 (Make 'fsck' able to[...], 2005-04-13), documented in c64b9b88605. Not emitted since 1024932f019 (fsck-cache: walk the 'refs' directory[...], 2005-05-18). - "missing sha1 directory": Added in 20222118ae4 (Add first cut at "fsck-cache"[...], 2005-04-08), documented in c64b9b88605. Not emitted since 230f13225df (Create object subdirectories on demand, 2005-10-08). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 21 January 2021, 03:10:42 UTC |
bfc2a36 | Jonathan Tan | 20 January 2021, 19:36:57 UTC | Doc: clarify contents of packfile sent as URI Clarify that, when the packfile-uri feature is used, the client should not assume that the extra packfiles downloaded would only contain a single blob, but support packfiles containing multiple objects of all types. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 21 January 2021, 03:06:50 UTC |
3831132 | Junio C Hamano | 15 January 2021, 02:51:02 UTC | ci/install-depends: attempt to fix "brew cask" stuff We run "git pull" against "$cask_repo"; clarify that we are expecting not to have any of our own modifications and running "git pull" to merely update, by passing "--ff-only" on the command line. Also, the "brew cask install" command line triggers an error message that says: Error: Calling brew cask install is disabled! Use brew install [--cask] instead. In addition, "brew install caskroom/cask/perforce" step triggers an error that says: Error: caskroom/cask was moved. Tap homebrew/cask instead. Attempt to see if blindly following the suggestion in these error messages gets us into a better shape. Signed-off-by: Junio C Hamano <gitster@pobox.com> | 15 January 2021, 03:08:56 UTC |
c9e3a4e | Jeff King | 12 January 2021, 15:52:32 UTC | patch-ids: handle duplicate hashmap entries This fixes a bug introduced in dfb7a1b4d0 (patch-ids: stop using a hand-rolled hashmap implementation, 2016-07-29) in which git rev-list --cherry-pick A...B will fail to suppress commits reachable from A even if a commit with matching patch-id appears in B. Around the time of that commit, the algorithm for "--cherry-pick" looked something like this: 0. Traverse all of the commits, marking them as being on the left or right side of the symmetric difference. 1. Iterate over the left-hand commits, inserting a patch-id struct for each into a hashmap, and pointing commit->util to the patch-id struct. 2. Iterate over the right-hand commits, checking which are present in the hashmap. If so, we exclude the commit from the output _and_ we mark the patch-id as "seen". 3. Iterate again over the left-hand commits, checking whether commit->util->seen is set; if so, exclude them from the output. At the end, we'll have eliminated commits from both sides that have a matching patch-id on the other side. But there's a subtle assumption here: for any given patch-id, we must have exactly one struct representing it. If two commits from A both have the same patch-id and we allow duplicates in the hashmap, then we run into a problem: a. In step 1, we insert two patch-id structs into the hashmap. b. In step 2, our lookups will find only one of these structs, so only one "seen" flag is marked. c. In step 3, one of the commits in A will have its commit->util->seen set, but the other will not. We'll erroneously output the latter. Prior to dfb7a1b4d0, our hashmap did not allow duplicates. Afterwards, it used hashmap_add(), which explicitly does allow duplicates. At that point, the solution would have been easy: when we are about to add a duplicate, skip doing so and return the existing entry which matches. But it gets more complicated. In 683f17ec44 (patch-ids: replace the seen indicator with a commit pointer, 2016-07-29), our step 3 goes away entirely. Instead, in step 2, when the right-hand side finds a matching patch_id from the left-hand side, we can directly mark the left-hand patch_id->commit to be omitted. Solving that would be easy, too; there's a one-to-many relationship of patch-ids to commits, so we just need to keep a list. But there's more. Commit b3dfeebb92 (rebase: avoid computing unnecessary patch IDs, 2016-07-29) built on that by lazily computing the full patch-ids. So we don't even know when adding to the hashmap whether two commits truly have the same id. We'd have to tentatively assign them a list, and then possibly split them apart (possibly into N new structs) at the moment we compute the real patch-ids. This could work, but it's complicated and error-prone. Instead, let's accept that we may store duplicates, and teach the lookup side to be more clever. Rather than asking for a single matching patch-id, it will need to iterate over all matching patch-ids. This does mean examining every entry in a single hash bucket, but the worst-case for a hash lookup was already doing that. We'll keep the hashmap details out of the caller by providing a simple iteration interface. We can retain the simple has_commit_patch_id() interface for the other callers, but we'll simplify its return value into an integer, rather than returning the patch_id struct. That way they won't be tempted to look at the "commit" field of the return value without iterating. Reported-by: Arnaud Morin <arnaud.morin@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 January 2021, 19:13:32 UTC |
a4a1ca2 | Taylor Blau | 11 January 2021, 19:25:10 UTC | Documentation/git-clone.txt: document race with --local When running 'git clone --local', the operation may fail if another process is modifying the source repository. Document that this race condition is known to hopefully help anyone who may run into it. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 12 January 2021, 06:03:08 UTC |
9371c0e | Ævar Arnfjörð Bjarmason | 11 January 2021, 13:14:51 UTC | gettext.c: remove/reword a mostly-useless comment Mostly remove the comment I added 5e9637c6297 (i18n: add infrastructure for translating Git with gettext, 2011-11-18). Since then we had a fix in 9c0495d23e6 (gettext.c: detect the vsnprintf bug at runtime, 2013-12-01) so we're not running with the "set back to C locale" hack on any modern system. So having more than 1/4 of the file taken up by a digression about a glibc bug that mostly doesn't happen to anyone anymore is just a needless distraction. Shorten the comment to make a brief mention of the bug, and where to find more info by looking at the git history for this now-removed comment. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 11 January 2021, 21:07:33 UTC |
450d740 | Ævar Arnfjörð Bjarmason | 11 January 2021, 13:14:50 UTC | Makefile: remove a warning about old GETTEXT_POISON flag Remove a migratory warning I added in 6cdccfce1e0 (i18n: make GETTEXT_POISON a runtime option, 2018-11-08) to give anyone using that option in their builds a heads-up about the change from compile-time to runtime introduced in that commit. It's been more than 2 years since then, anyone who ran into this is likely to have made a change as a result, so removing this is long overdue. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 11 January 2021, 21:07:30 UTC |
4eb56b5 | brian m. carlson | 10 January 2021, 19:04:48 UTC | docs: rephrase and clarify the git status --short format The table describing the porcelain format in git-status(1) is helpful, but it's not completely clear what the three sections mean, even to some contributors. As a result, users are unable to find how to detect common cases like merge conflicts programmatically. Let's improve this situation by rephrasing to be more explicit about what each of the sections in the table means, to tell users in plain language which cases are occurring, and to describe what "unmerged" means. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 11 January 2021, 20:14:07 UTC |
b356d23 | Utku Gultopu | 08 January 2021, 16:54:56 UTC | doc: remove "directory cache" from man pages "directory cache" (or "directory cache index", "cache") are obsolete terms which have been superseded by "index". Keeping them in the documentation may be a source of confusion. This commit replaces them with the current term, "index", on man pages. Signed-off-by: Utku Gultopu <ugultopu@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 10 January 2021, 06:57:24 UTC |
acaabcf | Jeff King | 10 January 2021, 03:23:09 UTC | t5516: loosen "not our ref" error check Commit 014ade7484 (upload-pack: send ERR packet for non-tip objects, 2019-04-13) added a test that greps the output of a failed fetch to make sure that upload-pack sent us the ERR packet we expected. But checking this is racy; despite the argument in that commit, the client may still be sending a "done" line after the server exits, causing it to die() on a failed write() and never see the ERR packet at all. This fails quite rarely on Linux, but more often on macOS. However, it can be triggered reliably with: diff --git a/fetch-pack.c b/fetch-pack.c index 876f90c759..cf40de9092 100644 --- a/fetch-pack.c +++ b/fetch-pack.c @@ -489,6 +489,7 @@ static int find_common(struct fetch_negotiator *negotiator, done: trace2_region_leave("fetch-pack", "negotiation_v0_v1", the_repository); if (!got_ready || !no_done) { + sleep(1); packet_buf_write(&req_buf, "done\n"); send_request(args, fd[1], &req_buf); } This is a real user-visible race that it would be nice to fix, but it's tricky to do so: the client would have to speculatively try to read an ERR packet after hitting a write() error. And at least for this error, it's specific to v0 (since v2 does not enforce reachability at all). So let's loosen the test to avoid annoying racy failures. If we eventually do the read-after-failed-write thing, we can tighten it. And if not, v0 will grow increasingly obsolete as servers support v2, so the utility of this test will decrease over time anyway. Note that we can still check stderr to make sure upload-pack bailed for the reason we expected. It writes a similar message to stderr, and because the server side is just another process connected by pipes, we'll reliably see it. This would not be the case for git://, or for ssh servers that do not relay stderr (e.g., GitHub's custom endpoint does not). Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 10 January 2021, 05:05:12 UTC |
a1e0353 | Adam Dinwoodie | 23 December 2020, 11:44:31 UTC | t4129: fix setfacl-related permissions failure When running this test in Cygwin, it's necessary to remove the inherited access control lists from the Git working directory in order for later permissions tests to work as expected. As such, fix an error in the test script so that the ACLs are set for the working directory, not a nonexistent subdirectory. Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Reviewed-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 09 January 2021, 22:45:26 UTC |
155067a | Vasyl Vavrychuk | 08 January 2021, 04:17:17 UTC | git-send-email.txt: mention less secure app access with Gmail Google may have changed Gmail security and now less secure app access needs to be explicitly enabled if two-factor authentication is not in place, otherwise send-email fails with: 5.7.8 Username and Password not accepted. Learn more at 5.7.8 https://support.google.com/mail/?p=BadCredentials Document steps required to make this work. Signed-off-by: Vasyl Vavrychuk <vvavrychuk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> [dl: Clean up commit message and incorporate suggestions into patch.] Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 08 January 2021, 06:44:28 UTC |
6c62f01 | Derrick Stolee | 08 January 2021, 02:30:46 UTC | for-each-repo: do nothing on empty config 'git for-each-repo --config=X' should return success without calling any subcommands when the config key 'X' has no value. The current implementation instead segfaults. A user could run into this issue if they used 'git maintenance start' to initialize their cron schedule using 'git for-each-repo --config=maintenance.repo ...' but then using 'git maintenance unregister' to remove the config option. (Note: 'git maintenance stop' would remove the config _and_ remove the cron schedule.) Add a simple test to ensure this works. Use 'git help --no-such-option' as the potential subcommand to ensure that we will hit a failure if the subcommand is ever run. Reported-by: Andreas Bühmann <dev@uuml.de> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 08 January 2021, 03:12:02 UTC |
0454986 | Junio C Hamano | 07 January 2021, 23:38:09 UTC | SubmittingPatches: tighten wording on "sign-off" procedure The text says "if you can certify DCO then you add a Signed-off-by trailer". But it does not say anything about people who cannot or do not want to certify. A natural reading may be that if you do not certify, you must not add the trailer, but it shouldn't hurt to be overly explicit. Signed-off-by: Junio C Hamano <gitster@pobox.com> | 07 January 2021, 23:41:36 UTC |
4045f65 | Ævar Arnfjörð Bjarmason | 07 January 2021, 09:51:53 UTC | branch: show "HEAD detached" first under reverse sort Change the output of the likes of "git branch -l --sort=-objectsize" to show the "(HEAD detached at <hash>)" message at the start of the output. Before the compare_detached_head() function added in a preceding commit we'd emit this output as an emergent effect. It doesn't make any sense to consider the objectsize, type or other non-attribute of the "(HEAD detached at <hash>)" message for the purposes of sorting. Let's always emit it at the top instead. The only reason it was sorted in the first place is because we're injecting it into the ref-filter machinery so builtin/branch.c doesn't need to do its own "am I detached?" detection. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 07 January 2021, 23:13:21 UTC |
2708ce6 | Ævar Arnfjörð Bjarmason | 07 January 2021, 09:51:52 UTC | branch: sort detached HEAD based on a flag Change the ref-filter sorting of detached HEAD to check the FILTER_REFS_DETACHED_HEAD flag, instead of relying on the ref description filled-in by get_head_description() to start with "(", which in turn we expect to ASCII-sort before any other reference. For context, we'd like the detached line to appear first at the start of "git branch -l", e.g.: $ git branch -l * (HEAD detached at <hash>) master This doesn't change that, but improves on a fix made in 28438e84e04 (ref-filter: sort detached HEAD lines firstly, 2019-06-18) and gives the Chinese translation the ability to use its preferred punctuation marks again. In Chinese the fullwidth versions of punctuation like "()" are typically written as (U+FF08 fullwidth left parenthesis), (U+FF09 fullwidth right parenthesis) instead[1]. This form is used in both po/zh_{CN,TW}.po in most cases where "()" is translated in a string. Aside from that improvement to the Chinese translation, it also just makes for cleaner code that we mark any special cases in the ref_array we're sorting with flags and make the sort function aware of them, instead of piggy-backing on the general-case of strcmp() doing the right thing. As seen in the amended tests this made reverse sorting a bit more consistent. Before this we'd sometimes sort this message in the middle, now it's consistently at the beginning or end, depending on whether we're doing a normal or reverse sort. Having it at the end doesn't make much sense either, but at least it behaves consistently now. A follow-up commit will make this behavior under reverse sorting even better. I'm removing the "TRANSLATORS" comments that were in the old code while I'm at it. Those were added in d4919bb288e (ref-filter: move get_head_description() from branch.c, 2017-01-10). I think it's obvious from context, string and translation memory in typical translation tools that these are the same or similar string. 1. https://en.wikipedia.org/wiki/Chinese_punctuation#Marks_similar_to_European_punctuation Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 07 January 2021, 23:13:21 UTC |
7c269a7 | Ævar Arnfjörð Bjarmason | 07 January 2021, 09:51:51 UTC | ref-filter: move ref_sorting flags to a bitfield Change the reverse/ignore_case/version sort flags in the ref_sorting struct into a bitfield. Having three of them was already a bit unwieldy, but it would be even more so if another flag needed a function like ref_sorting_icase_all() introduced in 76f9e569adb (ref-filter: apply --ignore-case to all sorting keys, 2020-05-03). A follow-up change will introduce such a flag, so let's move this over to a bitfield. Instead of using the usual '#define' pattern I'm using the "enum" pattern from builtin/rebase.c's b4c8eb024af (builtin rebase: support --quiet, 2018-09-04). Perhaps there's a more idiomatic way of doing the "for each in list amend mask" pattern than this "mask/on" variable combo. This function doesn't allow us to e.g. do any arbitrary changes to the bitfield for multiple flags, but I think in this case that's fine. The common case is that we're calling this with a list of one. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 07 January 2021, 23:13:21 UTC |
d094748 | Ævar Arnfjörð Bjarmason | 07 January 2021, 09:51:50 UTC | ref-filter: move "cmp_fn" assignment into "else if" arm Further amend code changed in 7c5045fc180 (ref-filter: apply fallback refname sort only after all user sorts, 2020-05-03) to move an assignment only used in the "else if" arm to happen there. Before that commit the cmp_fn would be used outside of it. We could also just skip the "cmp_fn" assignment and use strcasecmp/strcmp directly in a ternary statement here, but this is probably more readable. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 07 January 2021, 23:13:21 UTC |
75c50e5 | Ævar Arnfjörð Bjarmason | 07 January 2021, 09:51:49 UTC | ref-filter: add braces to if/else if/else chain Per the CodingGuidelines add braces to an if/else if/else chain where only the "else" had braces. This is in preparation for a subsequent change where the "else if" will have lines added to it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 07 January 2021, 23:13:21 UTC |
6aed567 | Jeff King | 07 January 2021, 09:44:17 UTC | fsck: reject .gitmodules git:// urls with newlines The previous commit taught the clone/fetch client side to reject a git:// URL with a newline in it. Let's also catch these when fscking a .gitmodules file, which will give an earlier warning. Note that it would be simpler to just complain about newline in _any_ URL, but an earlier tightening for http/ftp made sure we kept allowing newlines for unknown protocols (and this is covered in the tests). So we'll stick to that precedent. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 07 January 2021, 22:25:44 UTC |
a02ea57 | Jeff King | 07 January 2021, 09:43:58 UTC | git_connect_git(): forbid newlines in host and path When we connect to a git:// server, we send an initial request that looks something like: 002dgit-upload-pack repo.git\0host=example.com If the repo path contains a newline, then it's included literally, and we get: 002egit-upload-pack repo .git\0host=example.com This works fine if you really do have a newline in your repository name; the server side uses the pktline framing to parse the string, not newlines. However, there are many _other_ protocols in the wild that do parse on newlines, such as HTTP. So a carefully constructed git:// URL can actually turn into a valid HTTP request. For example: git://localhost:1234/%0d%0a%0d%0aGET%20/%20HTTP/1.1 %0d%0aHost:localhost%0d%0a%0d%0a becomes: 0050git-upload-pack / GET / HTTP/1.1 Host:localhost host=localhost:1234 on the wire. Again, this isn't a problem for a real Git server, but it does mean that feeding a malicious URL to Git (e.g., through a submodule) can cause it to make unexpected cross-protocol requests. Since repository names with newlines are presumably quite rare (and indeed, we already disallow them in git-over-http), let's just disallow them over this protocol. Hostnames could likewise inject a newline, but this is unlikely a problem in practice; we'd try resolving the hostname with a newline in it, which wouldn't work. Still, it doesn't hurt to err on the side of caution there, since we would not expect them to work in the first place. The ssh and local code paths are unaffected by this patch. In both cases we're trying to run upload-pack via a shell, and will quote the newline so that it makes it intact. An attacker can point an ssh url at an arbitrary port, of course, but unless there's an actual ssh server there, we'd never get as far as sending our shell command anyway. We _could_ similarly restrict newlines in those protocols out of caution, but there seems little benefit to doing so. The new test here is run alongside the git-daemon tests, which cover the same protocol, but it shouldn't actually contact the daemon at all. In theory we could make the test more robust by setting up an actual repository with a newline in it (so that our clone would succeed if our new check didn't kick in). But a repo directory with newline in it is likely not portable across all filesystems. Likewise, we could check git-daemon's log that it was not contacted at all, but we do not currently record the log (and anyway, it would make the test racy with the daemon's log write). We'll just check the client-side stderr to make sure we hit the expected code path. Reported-by: Harold Kim <h.kim@flatt.tech> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 07 January 2021, 22:25:44 UTC |
80f5a16 | Philippe Blain | 07 January 2021, 01:09:05 UTC | mergetool--lib: fix '--tool-help' to correctly show available tools Commit 83bbf9b92e (mergetool--lib: improve support for vimdiff-style tool variants, 2020-07-29) introduced a regression in the output of `git mergetool --tool-help` and `git difftool --tool-help` [1]. In function 'show_tool_names' in git-mergetool--lib.sh, we loop over the supported mergetools and their variants and accumulate them in the variable 'variants', separating them with a literal '\n'. The code then uses 'echo $variants' to turn these '\n' into newlines, but this behaviour is not portable, it just happens to work in some shells, like dash(1)'s 'echo' builtin. For shells in which 'echo' does not turn '\n' into newlines, the end result is that the only tools that are shown are the existing variants (except the last variant alphabetically), since the variants are separated by actual newlines in '$variants' because of the several 'echo' calls in mergetools/{bc,vimdiff}::list_tool_variants. Fix this bug by embedding an actual line feed into `variants` in show_tool_names(). While at it, replace `sort | uniq` by `sort -u`. To prevent future regressions, add a simple test that checks that a few known tools are correctly shown (let's avoid counting the total number of tools to lessen the maintenance burden when new tools are added or if '--tool-help' learns additional logic, like hiding tools depending on the current platform). [1] https://lore.kernel.org/git/CADtb9DyozjgAsdFYL8fFBEWmq7iz4=prZYVUdH9W-J5CKVS4OA@mail.gmail.com/ Reported-by: Philippe Blain <levraiphilippeblain@gmail.com> Based-on-patch-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> | 07 January 2021, 02:31:27 UTC |