What's cooking in git.git (Apr 2020, #01; Wed, 15)

What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Junio C Hamano]

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.

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Elijah Newren]

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.

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Junio C Hamano]

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.

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Damien Robert]

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/

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Jeff King]

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

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Junio C Hamano]

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.

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Damien Robert]

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

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Damien Robert]

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.

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Junio C Hamano]

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.

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Danh Doan]

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

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Junio C Hamano]

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.

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Damien Robert]

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)

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Danh Doan]

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

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Junio C Hamano]

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
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Junio C Hamano]

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".

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Damien Robert]

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

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Junio C Hamano]

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.

Re: What's cooking in git.git (Apr 2020, #01; Wed, 15)

[Damien Robert]

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)