* What's cooking in git.git (Apr 2020, #01; Wed, 15) @ 2020-04-15 23:01 Junio C Hamano 2020-04-16 15:28 ` Elijah Newren ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Junio C Hamano @ 2020-04-15 23:01 UTC (permalink / raw) To: git Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. Now the security fix is behind us, let's start merging things down to the 'next' branch. One topic that has been in the "held" state in 'next' has been reverted, and its replacement started cooking in 'pu'. Some topics are marked to be merged to 'next' in this report but have not been actually merged; a bit of knudging (or objection) to decide their fate is greatly appreciated, as usual. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -------------------------------------------------- [New Topics] * jk/use-quick-lookup-in-clone-for-tag-following (2020-04-01) 1 commit (merged to 'next' on 2020-04-15 at 11d6110e99) + clone: use "quick" lookup while following tags The logic to auto-follow tags by "git clone --single-branch" was not careful to avoid lazy-fetching unnecessary tags, which has been corrected. Will merge to 'master'. * ds/commit-graph-expiry-fix (2020-04-01) 1 commit - commit-graph: fix buggy --expire-time option "git commit-graph write --expire-time=<timestamp>" did not use the given timestamp correctly, which has been corrected. Will merge to 'next'. * ds/t5319-touch-fix (2020-04-01) 1 commit - t5319: replace 'touch -m' with 'test-tool chmtime' Tests update to use "test-chmtime" instead of "touch -t". Will merge to 'next'. * en/sequencer-reflog-action (2020-04-07) 1 commit (merged to 'next' on 2020-04-15 at 6c635bdaa1) + sequencer: honor GIT_REFLOG_ACTION "git rebase -i" did not leave the reflog entries correctly. Will merge to 'master'. * dd/no-gpg-sign (2020-04-03) 6 commits (merged to 'next' on 2020-04-15 at 3a326e99af) + Documentation: document merge option --no-gpg-sign + Documentation: merge commit-tree --[no-]gpg-sign + Documentation: reword commit --no-gpg-sign + Documentation: document am --no-gpg-sign + cherry-pick/revert: honour --no-gpg-sign in all case + rebase.c: honour --no-gpg-sign "git rebase" learned the "--no-gpg-sign" option to countermand commit.gpgSign the user may have. Will merge to 'master'. * en/rebase-doc-hooks-called-by-accident (2020-04-05) 1 commit - git-rebase.txt: add another hook to the hooks section, and explain more "git rebase" happens to call some hooks meant for "checkout" and "commit" by this was not a designed behaviour than historical accident. This has been documented. Will merge to 'next'. * jk/fast-import-use-hashmap (2020-04-06) 1 commit - fast-import: replace custom hash with hashmap.c The custom hash function used by "git fast-import" has been replaced with the one from hashmap.c, which gave us a nice performance boost. Will merge to 'next'. * js/t0007-typofix (2020-04-05) 1 commit (merged to 'next' on 2020-04-15 at ac9f86e08f) + t0007: fix a typo Typofix in a test script. Will merge to 'master'. * jt/avoid-prefetch-when-able-in-diff (2020-04-07) 4 commits - diff: restrict when prefetching occurs - diff: refactor object read - diff: make diff_populate_filespec_options struct - promisor-remote: accept 0 as oid_nr in function "git diff" in a partial clone learned to avoid lazy loading blob objects in more casese when they are not needed. Will merge to 'next'. * lx/submodule-clear-variables (2020-04-02) 1 commit - git-submodule.sh: setup uninitialized variables The "git submodule" command did not initialize a few variables it internally uses and was affected by variable settings leaked from the environment. Will merge to 'next'. * pb/pull-fetch-doc (2020-04-05) 2 commits (merged to 'next' on 2020-04-15 at cf530f230f) + pull doc: correct outdated description of an example + pull doc: refer to a specific section in 'fetch' doc The more aggressive updates to remote-tracking branches we had for the past 7 years or so were not reflected in the documentation, which has been corrected. Will merge to 'master'. * dd/ci-swap-azure-pipelines-with-github-actions (2020-04-10) 14 commits - ci: let GitHub Actions upload failed tests' directories - ci: add a problem matcher for GitHub Actions - tests: when run in Bash, annotate test failures with file name/line number - ci: retire the Azure Pipelines definition - README: add a build badge for the GitHub Actions runs - ci: configure GitHub Actions for CI/PR - ci: run gem with sudo to install asciidoctor - ci: explicit install all required packages - ci: fix the `jobname` of the `GETTEXT_POISON` job - ci/lib: set TERM environment variable if not exist - ci/lib: allow running in GitHub Actions - ci/lib: if CI type is unknown, show the environment variables - Merge branch 'dd/ci-musl-libc' into HEAD - Merge branch 'dd/test-with-busybox' into HEAD (this branch uses dd/ci-musl-libc and dd/test-with-busybox.) Update the CI configuration to use GitHub Actions, retiring the one based on Azure Pipelines. Will merge to 'next'. * eb/format-patch-no-encode-headers (2020-04-07) 1 commit (merged to 'next' on 2020-04-15 at 368840cd6c) + format-patch: teach --no-encode-email-headers The output from "git format-patch" uses RFC 2047 encoding for non-ASCII letters on From: and Subject: headers, so that it can directly be fed to e-mail programs. A new option has been added to produce these headers in raw. Will merge to 'master'. * js/mingw-fixes (2020-04-10) 3 commits (merged to 'next' on 2020-04-15 at 11a3d39d2b) + mingw: help debugging by optionally executing bash with strace + mingw: do not treat `COM0` as a reserved file name + mingw: use modern strftime implementation if possible Misc fixes for Windows. Will merge to 'master'. * js/stash-p-fix (2020-04-08) 2 commits - stash -p: (partially) fix bug concerning split hunks - t3904: fix incorrect demonstration of a bug Allowing the user to split a patch hunk while "git stash -p" does not work well; a band-aid has been added to make this (partially) work better. Will merge to 'next'. * js/subtree-doc-update-to-asciidoctor-2 (2020-04-08) 1 commit - subtree: fix build with AsciiDoctor 2 Doc markup update. Will merge to 'next'. * pw/rebase-i-more-options (2020-04-07) 7 commits - SQUASH??? - avoid test numbering crashes - t3433: improve coverage - Revert "sequencer: allow callers of read_author_script() to ignore fields" - rebase -i: fix --committer-date-is-author-date - t3433: only compare commit dates - t3433: remove loops from tests - Revert "Revert "Merge branch 'ra/rebase-i-more-options'"" "git rebase -i" learns a bit more options. Expecting a reroll. cf. <43d06bc0-b2ee-0ae6-f22c-9850e4033d45@gmail.com> * bc/constant-memequal (2020-04-09) 1 commit - builtin/receive-pack: use constant-time comparison for HMAC value Validation of push certificate has been made more robust against timing attacks. Will merge to 'next'. * ds/revision-show-pulls (2020-04-10) 1 commit (merged to 'next' on 2020-04-15 at 89b4d86a3a) + revision: --show-pulls adds helpful merges "git log" learned "--show-pulls" that helps pathspec limited history views; a merge commit that takes the whole change from a side branch, which is normally omitted from the output, is shown in addition to the commits that introduce real changes. Will merge to 'master'. * en/rebase-no-keep-empty (2020-04-11) 3 commits (merged to 'next' on 2020-04-15 at 9908cee7c0) + rebase: fix an incompatible-options error message + rebase: reinstate --no-keep-empty + rebase -i: mark commits that begin empty in todo editor (this branch is used by jt/rebase-allow-duplicate.) "git rebase" (again) learns to honor "--no-keep-empty", which lets the user to discard commits that are empty from the beginning (as opposed to the ones that become empty because of rebasing). The interactive rebase also marks commits that are empty in the todo. Will merge to 'master'. * jc/missing-ref-store-fix (2020-04-09) 2 commits (merged to 'next' on 2020-04-15 at 83caf48c7a) + repository: mark the "refs" pointer as private + sha1-name: do not assume that the ref store is initialized We've left the command line parsing of "git log :/a/b/" broken for about a full year without anybody noticing, which has been corrected. Will merge to 'master'. * jk/config-use-size-t (2020-04-10) 6 commits - config: reject parsing of files over INT_MAX - config: use size_t to store parsed variable baselen - git_config_parse_key(): return baselen as size_t - config: drop useless length variable in write_pair() - parse_config_key(): return subsection len as size_t - remote: drop auto-strlen behavior of make_branch() and make_rewrite() The config API made mixed uses of int and size_t types to represent length of various pieces of text it parsed, which has been updated to use the correct type (i.e. size_t) throughout. Will merge to 'next'. * js/flush-prompt-before-interative-input (2020-04-10) 2 commits (merged to 'next' on 2020-04-15 at 051407eb3a) + interactive: explicitly `fflush` stdout before expecting input + interactive: refactor code asking the user for interactive input The interactive input from various codepaths are consolidated and any prompt possibly issued earlier are fflush()ed before we read. Will merge to 'master'. * js/mingw-is-hidden-test-fix (2020-04-11) 3 commits (merged to 'next' on 2020-04-15 at 1e11f552f7) + t: restrict `is_hidden` to be called only on Windows + mingw: make test_path_is_hidden more robust + t: consolidate the `is_hidden` functions A Windows-specific test element has been made more robust against misuse from both user's environment and programmer's errors. Will merge to 'master'. * js/mingw-isilon-nfs (2020-04-10) 1 commit (merged to 'next' on 2020-04-15 at 4bac536980) + mingw: cope with the Isilon network file system Will merge to 'master'. * ma/config-doc-fix (2020-04-09) 1 commit (merged to 'next' on 2020-04-15 at 256175ec38) + config.txt: move closing "----" to cover entire listing Doc update. Will merge to 'master'. * ma/simplify-merge-config-parsing (2020-04-11) 1 commit (merged to 'next' on 2020-04-15 at d2915301e4) + merge: use skip_prefix to parse config key Code simplification. Will merge to 'master'. * ds/blame-on-bloom (2020-04-13) 4 commits - blame: use changed-path Bloom filters - commit-graph: write commit-graph in more tests - commit: write commit-graph with Bloom filters - revision: complicated pathspecs disable filters (this branch uses gs/commit-graph-path-filter.) "git blame" learns to take advantage of the "changed-paths" Bloom filter stored in the commit-graph file. * dd/iso-8601-updates (2020-04-15) 2 commits - date.c: allow compact version of ISO-8601 datetime - date.c: skip fractional second part of ISO-8601 The approxidate parser learns to parse seconds with fraction. Will merge to 'next'. * ds/log-exclude-decoration-config (2020-04-15) 2 commits - SQUASH??? - log: add log.excludeDecoration config option The "--decorate-refs" and "--decorate-refs-exclude" options "git log" takes have learned a companion configuration variable log.excludeDecoration that sits at the lowest priority in the family. Getting there. * jk/credential-parsing-end-of-host-in-URL (2020-04-15) 1 commit (merged to 'next' on 2020-04-15 at 55bc3eb7cb) + credential: treat "?" and "#" in URLs as end of host Parsing of URL for the credential helper has been corrected. Will merge to 'master'. * lr/freshen-file-fix (2020-04-15) 1 commit - freshen_file(): use NULL `times' for implicit current-time The code that refreshes the last access and modified time of on-disk packfiles and loose object files have been updated. Will merge to 'next'. * tb/commit-graph-split-strategy (2020-04-15) 7 commits - commit-graph.c: introduce '--[no-]check-oids' - commit-graph.h: replace 'commit_hex' with 'commits' - oidset: introduce 'oidset_size' - builtin/commit-graph.c: introduce split strategy 'replace' - builtin/commit-graph.c: introduce split strategy 'no-merge' - builtin/commit-graph.c: support for '--split[=<strategy>]' - t/helper/test-read-graph.c: support commit-graph chains "git commit-graph write" learned different ways to write out split files. -------------------------------------------------- [Stalled] * mk/use-size-t-in-zlib (2018-10-15) 1 commit - zlib.c: use size_t for size The wrapper to call into zlib followed our long tradition to use "unsigned long" for sizes of regions in memory, which have been updated to use "size_t". -------------------------------------------------- [Cooking] * gs/commit-graph-path-filter (2020-04-09) 16 commits - bloom: ignore renames when computing changed paths - commit-graph: add GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS test flag - t4216: add end to end tests for git log with Bloom filters - revision.c: add trace2 stats around Bloom filter usage - revision.c: use Bloom filters to speed up path based revision walks - commit-graph: add --changed-paths option to write subcommand - commit-graph: reuse existing Bloom filters during write - commit-graph: write Bloom filters to commit graph file - commit-graph: examine commits by generation number - commit-graph: examine changed-path objects in pack order - commit-graph: compute Bloom filters for changed paths - diff: halt tree-diff early after max_changes - bloom.c: core Bloom filter implementation for changed paths. - bloom.c: introduce core Bloom filter constructs - bloom.c: add the murmur3 hash implementation - commit-graph: define and use MAX_NUM_CHUNKS (this branch is used by ds/blame-on-bloom.) Introduce an extension to the commit-graph to make it efficient to check for the paths that were modified at each commit using Bloom filters. Getting there. * ag/rebase-merge-allow-ff-under-abbrev-command (2020-03-30) 2 commits (merged to 'next' on 2020-04-15 at b4679f7c7c) + t3432: test `--merge' with `rebase.abbreviateCommands = true', too + sequencer: don't abbreviate a command if it doesn't have a short form "git rebase" with the merge backend did not work well when the rebase.abbreviateCommands configuration was set. Will merge to 'master'. * jk/oid-array-cleanups (2020-03-30) 7 commits (merged to 'next' on 2020-04-15 at d6155cd023) + oidset: stop referring to sha1-array + ref-filter: stop referring to "sha1 array" + bisect: stop referring to sha1_array + test-tool: rename sha1-array to oid-array + oid_array: rename source file from sha1-array + oid_array: use size_t for iteration + oid_array: use size_t for count and allocation Code cleanup. Will merge to 'master'. * jx/proc-receive-hook (2020-04-15) 8 commits - SQUASH??? - doc: add documentation for the proc-receive hook - receive-pack: new config receive.procReceiveRefs - refs.c: refactor to reuse ref_is_hidden() - send-pack: extension for client-side status report - receive-pack: add new proc-receive hook - connect: export parse_feature_value() - transport: not report a non-head push as a branch "git receive-pack" that accepts requests by "git push" learned to outsource most of the ref updates to the new "proc-receive" hook. * dr/midx-avoid-int-underflow (2020-03-28) 1 commit (merged to 'next' on 2020-04-15 at eb2343a5eb) + midx.c: fix an integer underflow When fed a midx that records no objects, some codepaths tried to loop from 0 through (num_objects-1), which, due to integer arithmetic wrapping around, made it nonsense operation with out of bounds array accesses. The code has been corrected to reject such an midx file. Will merge to 'master'. * ak/run-command-on-cygwin-fix (2020-03-27) 1 commit (merged to 'next' on 2020-04-15 at 9e98b82a7f) + run-command: trigger PATH lookup properly on Cygwin Utitiles run via the run_command() API were not spawned correctly on Cygwin, when the paths to them are given as a full path with backslashes. Will merge to 'master'. * dd/ci-musl-libc (2020-04-06) 6 commits - travis: build and test on Linux with musl libc and busybox - ci/linux32: libify install-dependencies step - ci: refactor docker runner script - ci/linux32: parameterise command to switch arch - ci/lib-docker: preserve required environment variables - ci: make MAKEFLAGS available inside the Docker container in the Linux32 job (this branch is used by dd/ci-swap-azure-pipelines-with-github-actions.) A new CI job to build and run test suite on linux with musl libc has been added. Will merge to 'next'. * dr/doc-recurse-submodules (2020-04-06) 5 commits - doc: --recurse-submodules mostly applies to active submodules - doc: be more precise on (fetch|push).recurseSubmodules - doc: explain how to deactivate submodule.recurse completely - doc: document --recurse-submodules for reset and restore - doc: list all commands affected by submodule.recurse Documentation updates around the "--recurse-submodules" option. Will merge to 'next'. * dr/push-remoteref-fix (2020-04-06) 2 commits (merged to 'next' on 2020-04-15 at ecf60dc488) + remote.c: fix handling of %(push:remoteref) + remote.c: fix %(push) for triangular workflows The "%(push:remoteref)" placeholder in the "--format=" argument of "git format-patch" (and friends) only showed what got explicitly configured, not what ref at the receiving end would be updated when "git push" was used, as it ignored the default behaviour (e.g. update the same ref as the source). Will merge to 'master'. * jc/doc-test-leaving-early (2020-03-29) 1 commit - t/README: suggest how to leave test early with failure Document the recommended way to abort a failing test early (e.g. by exiting a loop), which is to say "return 1". Will merge to 'next'. * jk/build-with-right-curl (2020-04-05) 3 commits - Makefile: avoid running curl-config unnecessarily - Makefile: use curl-config --cflags - Makefile: avoid running curl-config multiple times The build procedure did not use the libcurl library and its include files correctly for a custom-built installation. On hold. cf. <20200404145829.GB679473@coredump.intra.peff.net> * jk/harden-protocol-v2-delim-handling (2020-03-29) 3 commits (merged to 'next' on 2020-04-15 at c983535405) + test-lib-functions: simplify packetize() stdin code + upload-pack: handle unexpected delim packets + test-lib-functions: make packetize() more efficient The server-end of the v2 protocol to serve "git clone" and "git fetch" was not prepared to see a delim packets at unexpected places, which led to a crash. Will merge to 'master'. * jk/p5310-drop-non-bitmap-timing (2020-03-27) 1 commit (merged to 'next' on 2020-04-15 at 7aac76cab2) + p5310: stop timing non-bitmap pack-to-disk Perf-test update. Will merge to 'master'. * jk/test-cleanup (2020-03-27) 2 commits (merged to 'next' on 2020-04-15 at bce8b2d5ed) + t/lib-*.sh: drop executable bit + t/lib-credential.sh: drop shebang line Test cleanup. Will merge to 'master'. * ps/transactional-update-ref-stdin (2020-04-02) 9 commits - update-ref: implement interactive transaction handling - update-ref: read commands in a line-wise fashion - update-ref: move transaction handling into `update_refs_stdin()` - update-ref: pass end pointer instead of strbuf - update-ref: drop unused argument for `parse_refname` - update-ref: organize commands in an array - strbuf: provide function to append whole lines - git-update-ref.txt: add missing word - refs: fix segfault when aborting empty transaction "git update-ref --stdin" learned a handful of new verbs to let the user control ref update transactions more explicitly, which helps as an ingredient to implement two-phase commit-style atomic ref-updates across multiple repositories. Will merge to 'next'. * ag/sequencer-i18n-messages (2020-03-28) 1 commit (merged to 'next' on 2020-04-15 at d6b38d12cf) + sequencer: mark messages for translation Message fix. Will merge to 'master'. * dl/wrapper-fix-indentation (2020-03-28) 1 commit (merged to 'next' on 2020-04-15 at e6b9c16b1b) + wrapper: indent with tabs Coding style fix. Will merge to 'master'. * en/pull-do-not-rebase-after-fast-forwarding (2020-03-27) 1 commit (merged to 'next' on 2020-04-15 at 3aa725ff45) + pull: avoid running both merge and rebase "git pull --rebase" tried to run a rebase even after noticing that the pull results in a fast-forward and no rebase is needed nor sensible, for the past few years due to a mistake nobody noticed. Will merge to 'master'. * jc/allow-strlen-substitution-in-shell-scripts (2020-03-29) 1 commit (merged to 'next' on 2020-04-15 at 262424efdc) + CodingGuidelines: allow ${#posix} == strlen($posix) Coding guideline update. Will merge to 'master'. * jm/gitweb-fastcgi-utf8 (2020-03-29) 1 commit (merged to 'next' on 2020-04-15 at adb7f2373a) + gitweb: fix UTF-8 encoding when using CGI::Fast Gitweb update. Will merge to 'master'. * js/walk-doc-optim (2020-03-30) 1 commit (merged to 'next' on 2020-04-15 at ca36c04a23) + MyFirstObjectWalk: remove unnecessary conditional statement Code cleanup. Will merge to 'master'. * jx/atomic-push (2020-03-29) 4 commits - transport-helper: new method reject_atomic_push() - transport-helper: mark failure for atomic push - send-pack: mark failure of atomic push properly - t5543: never report what we do not push "git push --atomic" used to show failures for refs that weren't even pushed, which has been corrected. Will merge to 'next'. * ma/doc-discard-docbook-xsl-1.73 (2020-03-31) 7 commits - user-manual.conf: don't specify [listingblock] - INSTALL: drop support for docbook-xsl before 1.74 - manpage-normal.xsl: fold in manpage-base.xsl - manpage-bold-literal.xsl: stop using git.docbook.backslash - Doc: drop support for docbook-xsl before 1.73.0 - Doc: drop support for docbook-xsl before 1.72.0 - Doc: drop support for docbook-xsl before 1.71.1 Raise the minimum required version of docbook-xsl package to 1.74, as 1.74.0 was from late 2008, which is more than 10 years old, and drop compatibility cruft from our documentation suite. Will merge to 'next'. * pb/rebase-doc-typofix (2020-03-28) 1 commit (merged to 'next' on 2020-04-15 at 8cd8422990) + git-rebase.txt: fix typo Typofix. Will merge to 'master'. * rs/pull-options-sync-code-and-doc (2020-03-28) 2 commits (merged to 'next' on 2020-04-15 at d743f43034) + pull: pass documented fetch options on + pull: remove --update-head-ok from documentation "git pull" shares many options with underlying "git fetch", but some of them were not documented and some of those that would make sense to pass down were not passed down. Will merge to 'master'. * en/fill-directory-exponential (2020-04-01) 12 commits - completion: fix 'git add' on paths under an untracked directory - Fix error-prone fill_directory() API; make it only return matches - dir: replace double pathspec matching with single in treat_directory() - dir: include DIR_KEEP_UNTRACKED_CONTENTS handling in treat_directory() - dir: replace exponential algorithm with a linear one - dir: refactor treat_directory to clarify control flow - dir: fix confusion based on variable tense - dir: fix broken comment - dir: consolidate treat_path() and treat_one_path() - dir: fix simple typo in comment - t3000: add more testcases testing a variety of ls-files issues - t7063: more thorough status checking The directory traversal code had redundant recursive calls which made its performance characteristics exponential with respect to the depth of the tree, which was corrected. Is this ready for 'next'? * dd/test-with-busybox (2020-03-26) 8 commits (merged to 'next' on 2020-04-15 at 8177191066) + t5703: feed raw data into test-tool unpack-sideband + t4124: tweak test so that non-compliant diff(1) can also be used + t7063: drop non-POSIX argument "-ls" from find(1) + t5616: use rev-parse instead to get HEAD's object_id + t5003: skip conversion test if unzip -a is unavailable + t5003: drop the subshell in test_lazy_prereq + test-lib-functions: test_cmp: eval $GIT_TEST_CMP + t4061: use POSIX compliant regex(7) (this branch is used by dd/ci-swap-azure-pipelines-with-github-actions.) Various tests have been updated to work around issues found with shell utilities that come with busybox etc. Will merge to 'master'. * dl/libify-a-few (2020-03-24) 2 commits - Lib-ify prune-packed - Lib-ify fmt-merge-msg Code in builtin/*, i.e. those can only be called from within built-in subcommands, that implements bulk of a couple of subcommands have been moved to libgit.a so that they could be used by others. Will merge to 'next'. * dl/test-must-fail-fixes-3 (2020-03-27) 8 commits (merged to 'next' on 2020-04-15 at dd0130c158) + t5801: teach compare_refs() to accept ! + t5612: stop losing return codes of git commands + t5612: don't use `test_must_fail test_cmp` + t5607: reorder `nongit test_must_fail` + t5550: simplify no matching line check + t5512: stop losing return codes of git commands + t5512: stop losing git exit code in here-docs + t5512: don't use `test_must_fail test_cmp` Test clean-up continues. Will merge to 'master'. * en/sparse-checkout (2020-03-27) 18 commits (merged to 'next' on 2020-04-15 at 3e295e445d) + sparse-checkout: provide a new reapply subcommand + unpack-trees: failure to set SKIP_WORKTREE bits always just a warning + unpack-trees: provide warnings on sparse updates for unmerged paths too + unpack-trees: make sparse path messages sound like warnings + unpack-trees: split display_error_msgs() into two + unpack-trees: rename ERROR_* fields meant for warnings to WARNING_* + unpack-trees: move ERROR_WOULD_LOSE_SUBMODULE earlier + sparse-checkout: use improved unpack_trees porcelain messages + sparse-checkout: use new update_sparsity() function + unpack-trees: add a new update_sparsity() function + unpack-trees: pull sparse-checkout pattern reading into a new function + unpack-trees: do not mark a dirty path with SKIP_WORKTREE + unpack-trees: allow check_updates() to work on a different index + t1091: make some tests a little more defensive against failures + unpack-trees: simplify pattern_list freeing + unpack-trees: simplify verify_absent_sparse() + unpack-trees: remove unused error type + unpack-trees: fix minor typo in comment "sparse-checkout" UI improvements. Will merge to 'master'. * js/import-tars-do-not-make-phony-files-from-pax-headers (2020-03-24) 1 commit (merged to 'next' on 2020-04-15 at 408afae2c9) + import-tars: ignore the global PAX header The import-tars importer (in contrib/fast-import/) used to create phony files at the top-level of the repository when the archive contains global PAX headers, which made its own logic to detect and omit the common leading directory ineffective, which has been corrected. Will merge to 'master'. * js/test-junit-finalization-fix (2020-03-23) 1 commit (merged to 'next' on 2020-04-15 at 0d6a975146) + tests(junit-xml): avoid invalid XML Test fix. Will merge to 'master'. * js/tests-gpg-integration-on-windows (2020-03-26) 5 commits (merged to 'next' on 2020-04-15 at 48a13eb0b2) + tests: increase the verbosity of the GPG-related prereqs + tests: turn GPG, GPGSM and RFC1991 into lazy prereqs + tests: do not let lazy prereqs inside `test_expect_*` turn off tracing + t/lib-gpg.sh: stop pretending to be a stand-alone script + tests(gpg): allow the gpg-agent to start on Windows Enable tests that require GnuPG on Windows. Will merge to 'master'. * dl/merge-autostash (2020-04-10) 22 commits - pull: pass --autostash to merge - t5520: make test_pull_autostash() accept expect_parent_num - merge: teach --autostash option - sequencer: implement apply_autostash_oid() - sequencer: implement save_autostash() - sequencer: unlink autostash in apply_autostash() - sequencer: extract perform_autostash() from rebase - rebase: generify create_autostash() - rebase: extract create_autostash() - reset: extract reset_head() from rebase - rebase: generify reset_head() - rebase: use apply_autostash() from sequencer.c - sequencer: rename stash_sha1 to stash_oid - sequencer: make apply_autostash() accept a path - rebase: use read_oneliner() - sequencer: make read_oneliner() extern - sequencer: configurably warn on non-existent files - sequencer: make read_oneliner() accept flags - sequencer: make file exists check more efficient - sequencer: stop leaking buf - t7600: use test_write_lines() - Makefile: ASCII-sort += lists "git merge" learns the "--autostash" option. Will merge to 'next'. * js/trace2-env-vars (2020-03-23) 1 commit (merged to 'next' on 2020-04-15 at 1aad0adfa0) + trace2: teach Git to log environment variables Trace2 enhancement to allow logging of the environment variables. Will merge to 'master'. * ar/test-style-fixes (2020-03-22) 2 commits (merged to 'next' on 2020-04-15 at 50ed75bccf) + t: fix whitespace around && + t9500: remove spaces after redirect operators Style fixes. Will merge to 'master'. * ds/doc-clone-filter (2020-03-22) 1 commit (merged to 'next' on 2020-04-15 at 16276689b3) + clone: document --filter options Doc update. Will merge to 'master'. * jk/t3419-drop-expensive-tests (2020-03-22) 1 commit (merged to 'next' on 2020-04-15 at a17ac8f996) + t3419: drop EXPENSIVE tests Test update. Will merge to 'master'. * jt/connectivity-check-optim-in-partial-clone (2020-03-29) 1 commit (merged to 'next' on 2020-04-15 at 1b3692b7fb) + connected: always use partial clone optimization Simplify the commit ancestry connectedness check in a partial clone repository in which "promised" objects are assumed to be obtainable lazily on-demand from promisor remote repositories. Will merge to 'master'. * mt/test-lib-bundled-short-options (2020-03-25) 1 commit (merged to 'next' on 2020-04-15 at 7fa0c56d91) + test-lib: allow short options to be bundled Minor test usability improvement. Will merge to 'master'. * bk/p4-pre-edit-changelist (2020-02-14) 7 commits (merged to 'next' on 2020-04-15 at 3e7cecd445) + git-p4: add RCS keyword status message + git-p4: add p4 submit hooks + git-p4: restructure code in submit + git-p4: add --no-verify option + git-p4: add p4-pre-submit exit text + git-p4: create new function run_git_hook + git-p4: rewrite prompt to be Windows compatible "git p4" learned four new hooks and also "--no-verify" option to bypass them (and the existing "p4-pre-submit" hook). Will merge to 'master'. * jt/rebase-allow-duplicate (2020-04-11) 1 commit (merged to 'next' on 2020-04-15 at 56a9d83adf) + rebase --merge: optionally skip upstreamed commits (this branch uses en/rebase-no-keep-empty.) Allow "git rebase" to reapply all local commits, even if the may be already in the upstream, without checking first. Will merge to 'master'. * bc/faq (2020-03-30) 1 commit (merged to 'next' on 2020-04-15 at 2d4c46ca7a) + docs: add a FAQ Doc update. Will merge to 'master'. * jc/log-no-mailmap (2020-03-16) 3 commits - log: give --[no-]use-mailmap a more sensible synonym --[no-]mailmap - clone: reorder --recursive/--recurse-submodules - parse-options: teach "git cmd -h" to show alias as alias "git log" learns "--[no-]mailmap" as a synonym to "--[no-]use-mailmap" Will merge to 'next'. * hn/reftable (2020-04-09) 11 commits - SQUASH??? - whitespace errors - SQUASH??? - do not forget to clean reftable library - Reftable support for git-core - Add reftable library - reftable: clarify how empty tables should be written - reftable: define version 2 of the spec to accomodate SHA256 - reftable: file format documentation - Add .gitattributes for the reftable/ directory - refs: document how ref_iterator_advance_fn should handle symrefs - create .git/refs in files-backend.c - refs.h: clarify reflog iteration order A new refs backend "reftable" to replace the traditional combination of packed-refs files and one-file-per-ref loose refs has been implemented and integrated for improved performance and atomicity. At v8. cf. <pull.539.v8.git.1585740538.gitgitgadget@gmail.com> * es/bugreport (2020-04-06) 5 commits - bugreport: add compiler info - bugreport: add uname info - bugreport: gather git version and build info - bugreport: add tool to generate debugging info - help: move list_config_help to builtin/help The "bugreport" tool. Will merge to 'next'. -------------------------------------------------- [Discarded] * jc/rebase-backend-keep-old-default (2020-03-10) 1 commit . rebase: do not switch the default to 'merge' just yet The "merge" backend of "git rebase" still has a few bugs and unexpected behaviour that need to be ironed out before it becomes the default. Let's switch the default back to the "apply" backend for now. * vn/reset-deleted-ita (2019-07-26) 1 commit . reset: unstage empty deleted ita files "git reset HEAD [<pathspec>]" did not reset an empty file that was added with the intent-to-add bit. * tb/commit-graph-split-merge (2020-03-24) 3 commits (merged to 'next' on 2020-03-31 at 2183baf09c) + builtin/commit-graph.c: support '--input=graphed' + builtin/commit-graph.c: introduce '--input=<source>' + builtin/commit-graph.c: support '--split[=<strategy>]' The code to write out the commit-graph has been taught a few options to control if the resulting graph chains should be merged or a single new incremental graph is created. Discarded---tb/commit-graph-split-strategy supersedes this. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-15 23:01 What's cooking in git.git (Apr 2020, #01; Wed, 15) Junio C Hamano @ 2020-04-16 15:28 ` Elijah Newren 2020-04-16 16:37 ` Junio C Hamano 2020-04-16 21:12 ` Damien Robert 2020-04-17 2:24 ` Danh Doan 2 siblings, 1 reply; 18+ messages in thread From: Elijah Newren @ 2020-04-16 15:28 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git Mailing List On Wed, Apr 15, 2020 at 6:13 PM Junio C Hamano <gitster@pobox.com> wrote: > * en/fill-directory-exponential (2020-04-01) 12 commits > - completion: fix 'git add' on paths under an untracked directory > - Fix error-prone fill_directory() API; make it only return matches > - dir: replace double pathspec matching with single in treat_directory() > - dir: include DIR_KEEP_UNTRACKED_CONTENTS handling in treat_directory() > - dir: replace exponential algorithm with a linear one > - dir: refactor treat_directory to clarify control flow > - dir: fix confusion based on variable tense > - dir: fix broken comment > - dir: consolidate treat_path() and treat_one_path() > - dir: fix simple typo in comment > - t3000: add more testcases testing a variety of ls-files issues > - t7063: more thorough status checking > > The directory traversal code had redundant recursive calls which > made its performance characteristics exponential with respect to > the depth of the tree, which was corrected. > > Is this ready for 'next'? I think it's as ready as it's going to get. I'm not aware of any current issues, am not planning further work barring a report or further review, and I'm feeling much better about it than when I first submitted it with a bunch of big warnings (though the big warnings it contains in that one commit message are still justified). I'm glad it spent a good long while in pu. My biggest worry with this series is that it might get merged just slightly before a release; I hope it either spends an average amount of time in next and then merges down quickly or else sits in next for a long time and merges at the beginning of the 2.28 cycle. Either way, at $DAYJOB I got a minor victory by getting many volunteers who will take newish git versions (as opposed to the old "please install at least git>=2.20.0), and I'm currently trying to set up a pipeline for them to get new versions easily. This series will be one of the things I include, in order generate more real-world testing. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-16 15:28 ` Elijah Newren @ 2020-04-16 16:37 ` Junio C Hamano 0 siblings, 0 replies; 18+ messages in thread From: Junio C Hamano @ 2020-04-16 16:37 UTC (permalink / raw) To: Elijah Newren; +Cc: Git Mailing List Elijah Newren <newren@gmail.com> writes: > I think it's as ready as it's going to get. I'm not aware of any > current issues, am not planning further work barring a report or > further review, and I'm feeling much better about it than when I first > submitted it with a bunch of big warnings (though the big warnings it > contains in that one commit message are still justified). I'm glad it > spent a good long while in pu. Thanks, let's mark it for 'next' then. By the way, I merged quite a large number of topics to 'next' yesterday. Those who want to polish their own topics further may want to check the status, so that they can switch to update incrementally from now on for topics that are already in 'next'. Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-15 23:01 What's cooking in git.git (Apr 2020, #01; Wed, 15) Junio C Hamano 2020-04-16 15:28 ` Elijah Newren @ 2020-04-16 21:12 ` Damien Robert 2020-04-16 21:30 ` Jeff King 2020-04-17 2:24 ` Danh Doan 2 siblings, 1 reply; 18+ messages in thread From: Damien Robert @ 2020-04-16 21:12 UTC (permalink / raw) To: Junio C Hamano; +Cc: git From Junio C Hamano, Wed 15 Apr 2020 at 16:01:52 (-0700) : > * dr/push-remoteref-fix (2020-04-06) 2 commits > (merged to 'next' on 2020-04-15 at ecf60dc488) > + remote.c: fix handling of %(push:remoteref) > + remote.c: fix %(push) for triangular workflows Hi Junio, I just sent a new version of this series, which drop the second patch for now. As outlined in my cover letter in https://public-inbox.org/git/20200406175648.25737-1-damien.olivier.robert+git@gmail.com/ the triangular workflow patch still leaves some corner cases (and for now is missing reviews). I'd prefer to fix all of them at once, rather than have an almost working patch. Jeff seems to be of the same opinion in https://public-inbox.org/git/20200406214607.GA1251506@coredump.intra.peff.net/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-16 21:12 ` Damien Robert @ 2020-04-16 21:30 ` Jeff King 2020-04-16 22:18 ` Junio C Hamano 0 siblings, 1 reply; 18+ messages in thread From: Jeff King @ 2020-04-16 21:30 UTC (permalink / raw) To: Damien Robert; +Cc: Junio C Hamano, git On Thu, Apr 16, 2020 at 11:12:08PM +0200, Damien Robert wrote: > From Junio C Hamano, Wed 15 Apr 2020 at 16:01:52 (-0700) : > > * dr/push-remoteref-fix (2020-04-06) 2 commits > > (merged to 'next' on 2020-04-15 at ecf60dc488) > > + remote.c: fix handling of %(push:remoteref) > > + remote.c: fix %(push) for triangular workflows > > Hi Junio, > > I just sent a new version of this series, which drop the second patch for > now. As outlined in my cover letter in > https://public-inbox.org/git/20200406175648.25737-1-damien.olivier.robert+git@gmail.com/ > the triangular workflow patch still leaves some corner cases (and for now > is missing reviews). > > I'd prefer to fix all of them at once, rather than have an almost working > patch. Jeff seems to be of the same opinion in > https://public-inbox.org/git/20200406214607.GA1251506@coredump.intra.peff.net/ Yeah, I'm sorry I haven't looked at the latest revision of the series. The security fix and some other stuff has been keeping me busy. If somebody else has time to review, please don't wait one me. But otherwise, it is on my list and I'll get to it eventually. -Peff ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-16 21:30 ` Jeff King @ 2020-04-16 22:18 ` Junio C Hamano 2020-04-16 22:47 ` Damien Robert 0 siblings, 1 reply; 18+ messages in thread From: Junio C Hamano @ 2020-04-16 22:18 UTC (permalink / raw) To: Jeff King; +Cc: Damien Robert, git Jeff King <peff@peff.net> writes: > On Thu, Apr 16, 2020 at 11:12:08PM +0200, Damien Robert wrote: > >> From Junio C Hamano, Wed 15 Apr 2020 at 16:01:52 (-0700): >> > * dr/push-remoteref-fix (2020-04-06) 2 commits >> > (merged to 'next' on 2020-04-15 at ecf60dc488) >> > + remote.c: fix handling of %(push:remoteref) >> > + remote.c: fix %(push) for triangular workflows >> >> Hi Junio, >> >> I just sent a new version of this series, which drop the second patch for >> now. As outlined in my cover letter in >> https://public-inbox.org/git/20200406175648.25737-1-damien.olivier.robert+git@gmail.com/ >> the triangular workflow patch still leaves some corner cases (and for now >> is missing reviews). >> >> I'd prefer to fix all of them at once, rather than have an almost working >> patch. Jeff seems to be of the same opinion in >> https://public-inbox.org/git/20200406214607.GA1251506@coredump.intra.peff.net/ > > Yeah, I'm sorry I haven't looked at the latest revision of the series. > The security fix and some other stuff has been keeping me busy. If > somebody else has time to review, please don't wait one me. But > otherwise, it is on my list and I'll get to it eventually. Thanks. In any case, they already are in 'next', so please update incrementally. In an early part of the development cycle of a topic, we tend to avoid building a topic from a horribly broken state and fix things up with pile of "oops, that was wrong, and here is a band-aid" patches, but once the patches become reviewable shape, the remaining "issues" tend to be the ones that are not found without careful reviewing and thinking things through, and it often is easier for later history inspection if the fixes are separate. Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-16 22:18 ` Junio C Hamano @ 2020-04-16 22:47 ` Damien Robert 2020-04-16 23:05 ` Damien Robert 0 siblings, 1 reply; 18+ messages in thread From: Damien Robert @ 2020-04-16 22:47 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeff King, git From Junio C Hamano, Thu 16 Apr 2020 at 15:18:47 (-0700) : > Thanks. In any case, they already are in 'next', so please update > incrementally. In an early part of the development cycle of a topic, we > tend to avoid building a topic from a horribly broken state and fix > things up with pile of "oops, that was wrong, and here is a band-aid" > patches, but once the patches become reviewable shape, the remaining > "issues" tend to be the ones that are not found without careful reviewing > and thinking things through, and it often is easier for later history > inspection if the fixes are separate. I am a bit confused because in next you picked both the original patch fixing the fallback to default %(push:remoteref) behavior, and the new RFC patch fixing triangular workflow (which has not yet been reviewed). But your argument seems to indicate you would have preferred two separate topics. That's indeed why the patch I sent today drops the triangular workflow patch for now. I think this is my fault, I should have sent the RFC patches fixing the triangular workflow which you picked (along with the original patch reviewed by Jeff) in a separate thread, so there were no risk of confusion (which was increased by the fact that my cover letter for this indicated version 4 while the patches were actually version 6). The triangular workflow patch is not quite correct in the sense that it does not handle (yet) all cases, but on the other hand you could argue that this is indeed better than the current code which is always wrong in the triangular case. Sorry I did not catch this sooner :-( -- Damien ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-16 22:47 ` Damien Robert @ 2020-04-16 23:05 ` Damien Robert 2020-04-16 23:34 ` Junio C Hamano 0 siblings, 1 reply; 18+ messages in thread From: Damien Robert @ 2020-04-16 23:05 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeff King, git From Damien Robert, Fri 17 Apr 2020 at 00:47:11 (+0200) : > The triangular workflow patch is not quite correct in the sense that it > does not handle (yet) all cases Here were the two reasons for the RFC of this patch e3165570dfca690ea1a71518799153f6350777ae - in is_workflow_triangular I compute the fetch and push remote. But the push remote is computed again in branch_get_remote_ref. So we redo an already done computation. - Also in struct remote *fetch_remote = remote_get(remote_for_branch(branch, NULL)); I don't check the value of *explicit. This means that I get the fallback of 'origin' if no remote is specified. So if I set a pushRemote="foobar" but no remote, then remote.c will consider we are in a triangular workflow but git push will not. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-16 23:05 ` Damien Robert @ 2020-04-16 23:34 ` Junio C Hamano 2020-04-17 12:54 ` Damien Robert 0 siblings, 1 reply; 18+ messages in thread From: Junio C Hamano @ 2020-04-16 23:34 UTC (permalink / raw) To: Damien Robert; +Cc: Jeff King, git Damien Robert <damien.olivier.robert@gmail.com> writes: > Here were the two reasons for the RFC of this patch e3165570dfca690ea1a71518799153f6350777ae > ... > This means that I get the fallback of 'origin' if no remote is specified. > So if I set a pushRemote="foobar" but no remote, then remote.c will > consider we are in a triangular workflow but git push will not. OK, so in short, what is queued in 'next' is quite borked X-<. I don't mind reverting the merge then. Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-16 23:34 ` Junio C Hamano @ 2020-04-17 12:54 ` Damien Robert 2020-04-17 17:30 ` Junio C Hamano 0 siblings, 1 reply; 18+ messages in thread From: Damien Robert @ 2020-04-17 12:54 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeff King, git From Junio C Hamano, Thu 16 Apr 2020 at 16:34:22 (-0700) : > > Here were the two reasons for the RFC of this patch e3165570dfca690ea1a71518799153f6350777ae > > ... > > This means that I get the fallback of 'origin' if no remote is specified. > > So if I set a pushRemote="foobar" but no remote, then remote.c will > > consider we are in a triangular workflow but git push will not. > OK, so in short, what is queued in 'next' is quite borked X-<. I > don't mind reverting the merge then. Yes sorry, I never meant for this patch version to be queued up, hence its rfc status :/ The reason I sent it as is, as outlined by my cover letter, was that I found it quite surprising that a pushRemote without remote was not considered by 'git push' as a triangular workflow. Technically a triangular workflow is when the push remote is different from the fetch remote, and we could argue when there is no fetch remote it is indeed the case (I know that was what I was expecting). So I was wondering if we should not change this logic in git push instead. I'll let you decide if you prefer reverting this merge, or applying the following fixup on top of next instead. --- 8< --- From 2f9268e2fb6ee280137fb928180882619eb9c3e5 Mon Sep 17 00:00:00 2001 From: Damien Robert <damien.olivier.robert+git@gmail.com> Date: Fri, 17 Apr 2020 14:41:02 +0200 Subject: [PATCH 1/1] remote.c: fix detection of triangular workflow When a branch has a pushRemote but no remote, then git push does not consider this as a triangular workflow. In remote.c, since is_workflow_triangular does not check for the *explicit value, it considers that such a branch is in a triangular workflow (except when 'pushRemote=origin' since the default non explicit value of fetch_remote is 'origin'). Fix that by checking the values of explicit in remote_for_branch and pushremote_for_branch, and add tests. Signed-off-by: Damien Robert <damien.olivier.robert+git@gmail.com> --- remote.c | 9 ++++++--- t/t6300-for-each-ref.sh | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 38 insertions(+), 3 deletions(-) diff --git a/remote.c b/remote.c index 7c99469598..18a190198a 100644 --- a/remote.c +++ b/remote.c @@ -1636,9 +1636,12 @@ static const char *tracking_for_push_dest(struct remote *remote, static int is_workflow_triangular(struct branch *branch) { - struct remote *fetch_remote = remote_get(remote_for_branch(branch, NULL)); - struct remote *push_remote = remote_get(pushremote_for_branch(branch, NULL)); - return (fetch_remote && push_remote && fetch_remote != push_remote); + int explicit; + struct remote *fetch_remote = remote_get(remote_for_branch(branch, &explicit)); + if (!explicit || !fetch_remote) + return 0; + struct remote *push_remote = remote_get(pushremote_for_branch(branch, &explicit)); + return (explicit && push_remote && fetch_remote != push_remote); } /** diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh index 8e59ab2567..4c01d4406f 100755 --- a/t/t6300-for-each-ref.sh +++ b/t/t6300-for-each-ref.sh @@ -945,6 +945,38 @@ test_expect_success '%(push) and %(push:remoteref)' ' --format="%(push:remotename),%(push:remoteref),%(push)" \ refs/heads/master)" && test to,refs/heads/master,refs/remotes/to/master = "$actual" && + actual="$(git -c push.default=nothing for-each-ref \ + --format="%(push:remotename),%(push:remoteref),%(push)" \ + refs/heads/master)" && + test to,, = "$actual" && + git config --unset branch.master.remote && + git config --unset branch.master.merge && + actual="$(git -c push.default=simple for-each-ref \ + --format="%(push:remotename),%(push:remoteref),%(push)" \ + refs/heads/master)" && + test to,, = "$actual" && + git config branch.master.merge refs/heads/master && + actual="$(git -c push.default=simple for-each-ref \ + --format="%(push:remotename),%(push:remoteref),%(push)" \ + refs/heads/master)" && + test to,, = "$actual" && + git config branch.master.merge refs/heads/other && + actual="$(git -c push.default=simple for-each-ref \ + --format="%(push:remotename),%(push:remoteref),%(push)" \ + refs/heads/master)" && + test to,, = "$actual" && + actual="$(git -c push.default=upstream for-each-ref \ + --format="%(push:remotename),%(push:remoteref),%(push)" \ + refs/heads/master)" && + test to,, = "$actual" && + actual="$(git -c push.default=current for-each-ref \ + --format="%(push:remotename),%(push:remoteref),%(push)" \ + refs/heads/master)" && + test to,refs/heads/master,refs/remotes/to/master = "$actual" && + actual="$(git -c push.default=matching for-each-ref \ + --format="%(push:remotename),%(push:remoteref),%(push)" \ + refs/heads/master)" && + test to,refs/heads/master,refs/remotes/to/master = "$actual" && actual="$(git -c push.default=nothing for-each-ref \ --format="%(push:remotename),%(push:remoteref),%(push)" \ refs/heads/master)" && -- Patched on top of v2.26.1-301-g55bc3eb7cb (git version 2.26.0) ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-17 12:54 ` Damien Robert @ 2020-04-17 17:30 ` Junio C Hamano 2020-04-17 22:04 ` Damien Robert 0 siblings, 1 reply; 18+ messages in thread From: Junio C Hamano @ 2020-04-17 17:30 UTC (permalink / raw) To: Damien Robert; +Cc: Jeff King, git Damien Robert <damien.olivier.robert@gmail.com> writes: > The reason I sent it as is, as outlined by my cover letter, was that I > found it quite surprising that a pushRemote without remote was not > considered by 'git push' as a triangular workflow. Technically a triangular > workflow is when the push remote is different from the fetch remote, and we > could argue when there is no fetch remote it is indeed the case (I know > that was what I was expecting). So I was wondering if we should not change > this logic in git push instead. If somebody can easily misunderstand how "push" makes decision about "triangular" (I presume builtin/push.c::is_workflow_triangular() is where that happens?) and changes what gets pushed and to where based on it, and writes a logic that is different when reporting what would happen when it is pushed out, there probably is a value in documenting the subtlety in a separate patch, just like you did in the follow-up fix below. As long as the fixed-up version is correct or is easily made more correct, that is. If the direction the initial patch tried to go was completely wrong and the follow-up needs to take a totally different approach, then it may be worth replacing wholesale. I am not getting an impression that the overall direction was wrong, though. > diff --git a/remote.c b/remote.c > index 7c99469598..18a190198a 100644 > --- a/remote.c > +++ b/remote.c > @@ -1636,9 +1636,12 @@ static const char *tracking_for_push_dest(struct remote *remote, > > static int is_workflow_triangular(struct branch *branch) > { > - struct remote *fetch_remote = remote_get(remote_for_branch(branch, NULL)); > - struct remote *push_remote = remote_get(pushremote_for_branch(branch, NULL)); > - return (fetch_remote && push_remote && fetch_remote != push_remote); > + int explicit; > + struct remote *fetch_remote = remote_get(remote_for_branch(branch, &explicit)); > + if (!explicit || !fetch_remote) > + return 0; > + struct remote *push_remote = remote_get(pushremote_for_branch(branch, &explicit)); > + return (explicit && push_remote && fetch_remote != push_remote); > } There is -Wdecl-after-statement error in this function to be corrected, but what the updated logic tries to do seems sensible, that is - given the "branch" we receive, we ask what remote is associated with it, and if it is explicitly configured or just the fallback value. If it is not configured, we declare the workflow is not triangular regardless of what pushremote is. - otherwise, i.e. when we do have an explicitly configured remote, we see what pushremote is configured for the branch. If it is not configured, or is the same as the remote for fetching, it is not triangular. Seeing the logic in builtin/push.c::is_workflow_triangular(), it is implemented quite differently, but I suspect it largely is because the actual logic "git push" uses can rely on the fact that it only needs to deal with the current branch. It does static int is_workflow_triangular(struct remote *remote) { struct remote *fetch_remote = remote_get(NULL); return (fetch_remote && fetch_remote != remote); } where "remote" is given by the caller, which is trying to push to the given "remote". We need to make sure the logic they decide what remote to push matches what you have above by checking what the caller does, but assuming that the "remote" the caller gives is the same as the push_remote you compute above, let's see if the fetch_remote they get is the same as what you compute in fetch_remote. They use remote.c::remote_get(NULL), which is a thin wrapper around remote.c::remote_get_1() and uses remote.c::remote_for_branch() on the current branch. Whether branch.*.remote is configured or not, what happens in remote_get_1() is mostly the same (it only affects if the url alias processing is done, but the only thing the two implementations of is_workflow_triangular() are interested in is the identity of the struct remote, which is not affected). The only case, as far as I can see, when their fetch_remote is NULL is when the remote they found did not have any URL for fetching (i.e. when valid_remote() check fails, remote_get_1() returns NULL). So, yes, when we are not fetching from the remote, which would be pushed to when on the branch, it is not triangular. But in determining it, they did not care if branch.*.remote is explicitly configured. But your updated version cares. Would that introduce behaviour difference, or is it a safe difference that does not matter? Now, where does the remote parameter in their implementation, which corresponds to push_remote computed in your version, come from? The caller of is_workflow_triangular() gets it from its caller: static void setup_default_push_refspecs(struct remote *remote) { struct branch *branch = branch_get(NULL); int triangular = is_workflow_triangular(remote); And its sole caller is builtin/push.c::do_push(), which in turn got it from its caller builtin/push.c::cmd_push(). I think for the purposes of formatting %(push), we should behave as if the branch we are formatting it for is the current branch and our "git push" does not say "where to", so what we want to see is what their version does where "git push" with no other arguments pushes to the current branch. cmd_push() asks remote.c::pushremote_get(NULL) and let remote_get_1() to use the "current_branch", but our code cannot afford to rely on that. We need to tell what branch we are interested in instead. Yours ask pushremote_for_branch() on the branch to obtain a remote, and then feed it to remote_get(). That's quite the same as what happens in the earlier part of remote_get_1(). One thing I notice is that pushremote_for_branch() depends on remote.c::pushremote_name file-scope static variable correctly read, but that is done at an early part of remote_get_1() by calling read_config(), so I think you are getting the same remote as do_push() is getting. But I do not see why the explicit bit matters here. Wasn't the goal to replicate what "git push" would do? Or is there anything more subtle going on? Puzzled. With the attached stripped-down configuration in a test repository, running "git push" while on 'master' seems to think the workflow is triangular, as builtin/push.c::is_workflow_triangular() sees remote->name == "publish" and fetch_remote->name == "origin" (it is easy to see that in a debugger). If you drop remote.origin.url from the configuration and run the same experiment, fetch_remote will be NULL, as valid_remote() check in remote_get_1() declares that the remote "origin", which is created by default, is invalid without any URL. So, are you sure that "lack of branch.*.remote makes the workflow triangular in push but not your %(push)" is correct? Is there something else going on? Thanks. ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- [branch "master"] pushremote = publish [remote "publish"] url = . [remote "origin"] url = ../somewhere-else ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-17 17:30 ` Junio C Hamano @ 2020-04-17 22:04 ` Damien Robert 2020-04-17 23:22 ` Junio C Hamano 0 siblings, 1 reply; 18+ messages in thread From: Damien Robert @ 2020-04-17 22:04 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeff King, git Just a quick answeŗ, I'll give a more complete one afterwards. From Junio C Hamano, Fri 17 Apr 2020 at 10:30:53 (-0700) : > ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- > [branch "master"] > pushremote = publish > > [remote "publish"] > url = . > > [remote "origin"] > url = ../somewhere-else > ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- If you remove the remote "origin", then struct remote *fetch_remote = remote_get(NULL); used by pull.c will return NULL: it fallbacks to 'origin' which does not exist, so remote_get_1 in if (!valid_remote(ret)) return NULL; returns NULL But is_workflow_triangular in struct remote *fetch_remote = remote_get(remote_for_branch(branch, &explicit); ); returns "origin" The difference in remote_get_1 is that name_given = 1; So if (name_given && !valid_remote(ret)) add_url_alias(ret, name); gets called. But I think that means that my fixup is actually wrong when a pushRemote is set without a remote while 'origin' do exist. I'll need to test. Grmpf! Thanks a lot for the thorough review! -- Damien Robert http://www.normalesup.org/~robert/pro ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-17 22:04 ` Damien Robert @ 2020-04-17 23:22 ` Junio C Hamano 2020-04-18 17:36 ` Damien Robert 0 siblings, 1 reply; 18+ messages in thread From: Junio C Hamano @ 2020-04-17 23:22 UTC (permalink / raw) To: Damien Robert; +Cc: Jeff King, git Damien Robert <damien.olivier.robert@gmail.com> writes: > The difference in remote_get_1 is that > name_given = 1; > So > if (name_given && !valid_remote(ret)) > add_url_alias(ret, name); > gets called. Ah, of course ;-) The code in builtin/push.c rely on being able to pass NULL as the name and rely on current branch getting used; you have to pass the name of the ref you are trying to format %(push) for, so you would trigger add_url_alias(), which says as a fallback that URL for "origin" is "origin" and makes ret->url non-NULL (hence it no longer is !valid_remote() and gets returned). Geez. This is tricky. > But I think that means that my fixup is actually wrong when a pushRemote is > set without a remote while 'origin' do exist. Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-17 23:22 ` Junio C Hamano @ 2020-04-18 17:36 ` Damien Robert 0 siblings, 0 replies; 18+ messages in thread From: Damien Robert @ 2020-04-18 17:36 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jeff King, git From Junio C Hamano, Fri 17 Apr 2020 at 16:22:06 (-0700) : > Ah, of course ;-) The code in builtin/push.c rely on being able to > pass NULL as the name and rely on current branch getting used; you > have to pass the name of the ref you are trying to format %(push) > for, so you would trigger add_url_alias(), which says as a fallback > that URL for "origin" is "origin" and makes ret->url non-NULL (hence > it no longer is !valid_remote() and gets returned). Indeed, if 'origin' is implicit and does not exists, then remote_get(NULL) returns NULL, while remote_get(remote_for_branch(current_branch, NULL)) returns the 'origin' remote Likewise pushremote_get(NULL) will differ from remote_get(pushremote_for_branch(current_branch, NULL)) if 'origin' is the implicit push remote and does not exists. In particular, there is currently no way to check with remote_get("origin") if an implicit 'origin' really exists or not. What we would need to get the same results is an extra parameter to remote_get_1 which tells it if the given name was obtained explicitly or implicitly. Now this induces some bugs in the ref-filter machinery. For instance, for %(upstream:remotename) and %(push:remotename), the code prints `remote_for_branch(branch, &explicit)` and `pushremote_for_branch(branch, &explicit)` respectively only if they are explicit. But this is not quite correct, if we think of %(upstream:remotename) as to "which remote would a bare `git fetch` contact when on this branch?"; then 'origin' should be printed, provided it really exists. > Geez. This is tricky. > > But I think that means that my fixup is actually wrong when a pushRemote is > > set without a remote while 'origin' do exist. So here is a test done about whether a triangular setup is detected, when a branch has a pushRemote but no remote and 1) pushRemote=foobar, origin does not exists 2) pushRemote=foobar, origin does exists 3) pushRemote=origin, origin does not exists 4) pushRemote=origin, origin exists in the following cases: A) `git push` B) "%(push)" with the code currently in next C) "%(push)" with the fixup I sent D) what I would have expected A B C D 1 no yes no yes 2 yes yes no yes 3 no no no no 4 no no no no Assuming D is indeed the correct way to go, there are two ways to fix is_workflow_triangular in push.c (not tested): one is to replace return (fetch_remote && fetch_remote != remote); by return (!fetch_remote || fetch_remote != remote); Indeed in this case we know that the push remote exists, so if the fetch_remote does not exists, we know we are in a triangular workflow. Another way would be to call fetch_remotename=remote_for_branch(current_branch, &explicit); and compare it with remote->name. Going back to my 'fixup', it is clearly wrong (in the opposite direction of what is currently in next!). But assuming that 'D' is what we want for triangular workflows, the patch in next is actually correct and it is `git push` who is wrong :) About the patch currently in next, apart from this situation which is tricky to fix as you observed, one thing I may have changed if you had not commited it already is to change static int is_workflow_triangular(struct branch *branch) into static int is_workflow_triangular(struct branch *branch, struct remote *push_remote) since all the callers already have the push_remote, this would prevent us from recomputing it. But this can be a separate fix, if you think this does not warrant a revert of the merge. PS: While I am on the subject of bugs in ref-filter.c, for exhaustivity, in push.c `setup_push_upstream` checks that (branch->merge_nr != 1) but this is not done for %(push) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-15 23:01 What's cooking in git.git (Apr 2020, #01; Wed, 15) Junio C Hamano 2020-04-16 15:28 ` Elijah Newren 2020-04-16 21:12 ` Damien Robert @ 2020-04-17 2:24 ` Danh Doan 2020-04-17 5:38 ` Junio C Hamano 2 siblings, 1 reply; 18+ messages in thread From: Danh Doan @ 2020-04-17 2:24 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On 2020-04-15 16:01:52-0700, Junio C Hamano <gitster@pobox.com> wrote: > * dd/iso-8601-updates (2020-04-15) 2 commits > - date.c: allow compact version of ISO-8601 datetime > - date.c: skip fractional second part of ISO-8601 > > The approxidate parser learns to parse seconds with fraction. > > Will merge to 'next'. I thought we haven't gained enough concious for "12:34:56.7.days.ago" Current code will treat it as "7 days ago at 12:34:56" New code will treat it as 12:34:56 (today?) -- Danh ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-17 2:24 ` Danh Doan @ 2020-04-17 5:38 ` Junio C Hamano 2020-04-17 13:36 ` Danh Doan 0 siblings, 1 reply; 18+ messages in thread From: Junio C Hamano @ 2020-04-17 5:38 UTC (permalink / raw) To: Danh Doan; +Cc: git Danh Doan <congdanhqx@gmail.com> writes: > On 2020-04-15 16:01:52-0700, Junio C Hamano <gitster@pobox.com> wrote: >> * dd/iso-8601-updates (2020-04-15) 2 commits >> - date.c: allow compact version of ISO-8601 datetime >> - date.c: skip fractional second part of ISO-8601 >> >> The approxidate parser learns to parse seconds with fraction. >> >> Will merge to 'next'. > > I thought we haven't gained enough concious for "12:34:56.7.days.ago" > Current code will treat it as "7 days ago at 12:34:56" > New code will treat it as 12:34:56 (today?) Yup, it clearly is a regression, and I do not think there is an agreement that the regression matters in real life. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-17 5:38 ` Junio C Hamano @ 2020-04-17 13:36 ` Danh Doan 2020-04-17 17:40 ` Junio C Hamano 0 siblings, 1 reply; 18+ messages in thread From: Danh Doan @ 2020-04-17 13:36 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On 2020-04-16 22:38:16-0700, Junio C Hamano <gitster@pobox.com> wrote: > Danh Doan <congdanhqx@gmail.com> writes: > > > On 2020-04-15 16:01:52-0700, Junio C Hamano <gitster@pobox.com> wrote: > >> * dd/iso-8601-updates (2020-04-15) 2 commits > >> - date.c: allow compact version of ISO-8601 datetime > >> - date.c: skip fractional second part of ISO-8601 > >> > >> The approxidate parser learns to parse seconds with fraction. > >> > >> Will merge to 'next'. > > > > I thought we haven't gained enough concious for "12:34:56.7.days.ago" > > Current code will treat it as "7 days ago at 12:34:56" > > New code will treat it as 12:34:56 (today?) > > Yup, it clearly is a regression, and I do not think there is an > agreement that the regression matters in real life. > Well, I _think_ we should keep it in pu to see other's feedback for now. Even if we want to advance it to next, I would like to have this fixup for the documentation the first patch. --------------8<------------- Subject: [PATCH] fixup! date.c: skip fractional second part of ISO-8601 Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> --- Documentation/date-formats.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/date-formats.txt b/Documentation/date-formats.txt index 6f69ba2ddd..7e7eaba643 100644 --- a/Documentation/date-formats.txt +++ b/Documentation/date-formats.txt @@ -20,7 +20,10 @@ RFC 2822:: ISO 8601:: Time and date specified by the ISO 8601 standard, for example `2005-04-07T22:13:13`. The parser accepts a space instead of the - `T` character as well. The fractional part will be ignored. + `T` character as well. Fractional parts of a second will be ignored, + for example `2005-04-07T22:13:13.019` will be treated as + `2005-04-07T22:13:13` + + NOTE: In addition, the date part is accepted in the following formats: `YYYY.MM.DD`, `MM/DD/YYYY` and `DD.MM.YYYY`. -- Danh ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: What's cooking in git.git (Apr 2020, #01; Wed, 15) 2020-04-17 13:36 ` Danh Doan @ 2020-04-17 17:40 ` Junio C Hamano 0 siblings, 0 replies; 18+ messages in thread From: Junio C Hamano @ 2020-04-17 17:40 UTC (permalink / raw) To: Danh Doan; +Cc: git Danh Doan <congdanhqx@gmail.com> writes: > On 2020-04-16 22:38:16-0700, Junio C Hamano <gitster@pobox.com> wrote: >> Danh Doan <congdanhqx@gmail.com> writes: >> >> > On 2020-04-15 16:01:52-0700, Junio C Hamano <gitster@pobox.com> wrote: >> >> * dd/iso-8601-updates (2020-04-15) 2 commits >> >> - date.c: allow compact version of ISO-8601 datetime >> >> - date.c: skip fractional second part of ISO-8601 >> >> >> >> The approxidate parser learns to parse seconds with fraction. >> >> >> >> Will merge to 'next'. >> > >> > I thought we haven't gained enough concious for "12:34:56.7.days.ago" >> > Current code will treat it as "7 days ago at 12:34:56" >> > New code will treat it as 12:34:56 (today?) >> >> Yup, it clearly is a regression, and I do not think there is an >> agreement that the regression matters in real life. >> > > Well, I _think_ we should keep it in pu to see other's feedback for now. Thanks. Will mark it as "On Hold". ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2020-04-18 17:37 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-15 23:01 What's cooking in git.git (Apr 2020, #01; Wed, 15) Junio C Hamano 2020-04-16 15:28 ` Elijah Newren 2020-04-16 16:37 ` Junio C Hamano 2020-04-16 21:12 ` Damien Robert 2020-04-16 21:30 ` Jeff King 2020-04-16 22:18 ` Junio C Hamano 2020-04-16 22:47 ` Damien Robert 2020-04-16 23:05 ` Damien Robert 2020-04-16 23:34 ` Junio C Hamano 2020-04-17 12:54 ` Damien Robert 2020-04-17 17:30 ` Junio C Hamano 2020-04-17 22:04 ` Damien Robert 2020-04-17 23:22 ` Junio C Hamano 2020-04-18 17:36 ` Damien Robert 2020-04-17 2:24 ` Danh Doan 2020-04-17 5:38 ` Junio C Hamano 2020-04-17 13:36 ` Danh Doan 2020-04-17 17:40 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).