What's cooking in git.git (Dec 2018, #01; Sun, 9)

What's cooking in git.git (Dec 2018, #01; Sun, 9)

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

Git 2.20 has been tagged.  I'd expect that we would slow down to see
how stable it is and queue only the brown-paper-bag fixes for a week
or so, before opening the tree for the next cycle, rewinding the tip
of 'next', etc.

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

--------------------------------------------------
[Graduated to "master"]

* ab/push-example-in-doc (2018-11-14) 1 commit
  (merged to 'next' on 2018-11-18 at 8fd935a19c)
 + push: change needlessly ambiguous example in error

 An error message that sugggests how to give correct arguments to
 "git push" has been updated.


* ab/replace-graft-with-replace-advice (2018-11-29) 1 commit
  (merged to 'next' on 2018-11-30 at c5d658e075)
 + advice: don't pointlessly suggest --convert-graft-file

 The advice message to tell the user to migrate an existing graft
 file to the replace system when a graft file was read was shown
 even when "git replace --convert-graft-file" command, which is the
 way the message suggests to use, was running, which made little
 sense.


* gh/diff-raw-has-no-ellipses (2018-11-26) 1 commit
  (merged to 'next' on 2018-11-29 at 24a7536f15)
 + doc: update diff-format.txt for removed ellipses in --raw

 "git diff --raw" lost ellipses to adjust the output columns for
 some time now, but the documentation still showed them.


* jc/format-patch-range-diff-fix (2018-11-30) 1 commit
  (merged to 'next' on 2018-11-30 at 26290b1ec1)
 + format-patch: do not let its diff-options affect --range-diff

 "git format-patch --range-diff" by mistake passed the diff options
 used to generate the primary output of the command to the
 range-diff machinery, which caused the range-diff in the cover
 letter to include fairly useless "--stat" output.  This has been
 corrected by forcing a non-customizable default formatting options
 on the range-diff machinery when driven by format-patch.


* js/rebase-reflog-action-fix (2018-11-30) 1 commit
  (merged to 'next' on 2018-11-30 at 93fd2fb920)
 + rebase: fix GIT_REFLOG_ACTION regression

 "git rebase" reimplemented recently in C accidentally changed the
 way reflog entries are recorded (earlier "rebase -i" identified the
 entries it leaves with "rebase -i", but the new version always
 marks them with "rebase").  This has been corrected.


* js/rebase-stat-unrelated-fix (2018-11-30) 1 commit
  (merged to 'next' on 2018-11-30 at a9faaff8c1)
 + rebase --stat: fix when rebasing to an unrelated history

 "git rebase --stat" to transplant a piece of history onto a totally
 unrelated history were not working before and silently showed wrong
 result.  With the recent reimplementation in C, it started to instead
 die with an error message, as the original logic was not prepared
 to cope with this case.  This has now been fixed.


* ma/reset-doc-rendering-fix (2018-11-29) 2 commits
  (merged to 'next' on 2018-11-30 at be718c19e2)
 + git-reset.txt: render literal examples as monospace
 + git-reset.txt: render tables correctly under Asciidoctor

 Doc updates.


* rt/rebase-in-c-message-fix (2018-12-01) 1 commit
  (merged to 'next' on 2018-12-01 at 4428c15a66)
 + builtin/rebase.c: remove superfluous space in messages


* sg/daemon-test-signal-fix (2018-11-27) 1 commit
  (merged to 'next' on 2018-11-30 at b3f7fdf727)
 + t/lib-git-daemon: fix signal checking

 Test fix.


* sg/test-BUG (2018-11-20) 1 commit
  (merged to 'next' on 2018-11-21 at bb81013952)
 + tests: send "bug in the test script" errors to the script's stderr

 test framework has been updated to make a bug in the test script
 (as opposed to bugs in Git that are discovered by running the
 tests) stand out more prominently.


* sg/test-cmp-rev (2018-11-20) 1 commit
  (merged to 'next' on 2018-11-21 at 5d65cb2a76)
 + test-lib-functions: make 'test_cmp_rev' more informative on failure

 Test framework update.


* ss/msvc-strcasecmp (2018-11-20) 1 commit
  (merged to 'next' on 2018-11-21 at 9e45649e6e)
 + msvc: directly use MS version (_stricmp) of strcasecmp

 MSVC update.

--------------------------------------------------
[New Topics]

* cb/openbsd-allows-reading-directory (2018-12-03) 1 commit
 - config.mak.uname: OpenBSD uses BSD semantics with fread for directories

 BSD port update.

 Will merge to 'next'.


* cb/t5004-empty-tar-archive-fix (2018-12-03) 1 commit
 - t5004: avoid using tar for empty packages

 BSD port update.

 Will merge to 'next'.


* cb/test-lint-cp-a (2018-12-03) 1 commit
 - tests: add lint for non portable cp -a

 BSD port update.

 Will merge to 'next'.


* hb/t0061-dot-in-path-fix (2018-12-03) 1 commit
 - t0061: do not fail test if '.' is part of $PATH

 Test update.

 Will merge to 'next'.


* hn/highlight-sideband-keywords (2018-12-04) 1 commit
 - sideband: color lines with keyword only

 Lines that begin with a certain keyword that come over the wire, as
 well as lines that consist only of one of these keywords, ought to
 be painted in color for easier eyeballing, but the latter was
 broken ever since the feature was introduced in 2.19, which has
 been corrected.

 Will merge to 'next'.


* js/commit-graph-chunk-table-fix (2018-12-09) 4 commits
 - SQUASH???
 - Makefile: correct example fuzz build
 - commit-graph: fix buffer read-overflow
 - commit-graph, fuzz: add fuzzer for commit-graph

 The codepath to read from the commit-graph file attempted to read
 past the end of it when the file's table-of-contents was corrupt.


* jt/get-reference-with-commit-graph (2018-12-06) 1 commit
 - revision: use commit graph in get_reference()
 (this branch uses sb/more-repo-in-api.)

 Micro-optimize the code that prepares commit objects to be walked
 by "git rev-list" when the commit-graph is available.

 Will merge to 'next'.


* md/exclude-promisor-objects-fix-cleanup (2018-12-06) 1 commit
 - revision.c: put promisor option in specialized struct

 Code clean-up.

 Will merge to 'next'.


* bw/mailmap (2018-12-09) 1 commit
 - mailmap: update Brandon Williams's email address

 Will merge to 'next'.


* do/gitweb-strict-export-conf-doc (2018-12-09) 1 commit
 - docs: fix $strict_export text in gitweb.conf.txt

 Doc update.

 Will merge to 'next'.


* en/directory-renames-nothanks-doc-update (2018-12-09) 1 commit
 - git-rebase.txt: update note about directory rename detection and am

 Doc update.

 Will merge to 'next'.


* fd/gitweb-snapshot-conf-doc-fix (2018-12-09) 1 commit
 - docs/gitweb.conf: config variable typo

 Doc update.

 Will merge to 'next'.


* km/rebase-doc-typofix (2018-12-09) 1 commit
 - rebase docs: drop stray word in merge command description

 Doc update.

 Will merge to 'next'.


* nd/indentation-fix (2018-12-09) 1 commit
 - Indent code with TABs

 Code cleanup.

 Will merge to 'next'.


* tb/use-common-win32-pathfuncs-on-cygwin (2018-12-09) 1 commit
 - git clone <url> C:\cygwin\home\USER\repo' is working (again)

 Cygwin update.

 Will merge to 'next'.

--------------------------------------------------
[Stalled]

* lt/date-human (2018-07-09) 1 commit
 - Add 'human' date format

 A new date format "--date=human" that morphs its output depending
 on how far the time is from the current time has been introduced.
 "--date=auto" can be used to use this new format when the output is
 goint to the pager or to the terminal and otherwise the default
 format.

--------------------------------------------------
[Cooking]

* mk/http-backend-kill-children-before-exit (2018-11-26) 1 commit
  (merged to 'next' on 2018-11-29 at bf2d45062f)
 + http-backend: enable cleaning up forked upload/receive-pack on exit

 The http-backend CGI process did not correctly clean up the child
 processes it spawns to run upload-pack etc. when it dies itself,
 which has been corrected.

 Will cook in 'next'.


* tb/log-G-binary (2018-11-29) 1 commit
 - log -G: ignore binary files

 "git log -G<regex>" looked for a hunk in the "git log -p" patch
 output that contained a string that matches the given pattern.
 Optimize this code to ignore binary files, which by default will
 not show any hunk that would match any pattern (unless textconv or
 the --text option is in effect, that is).

 Expecting an update to the tests.


* dl/merge-cleanup-scissors-fix (2018-11-21) 2 commits
  (merged to 'next' on 2018-11-21 at 217be06acb)
 + merge: add scissors line on merge conflict
 + t7600: clean up 'merge --squash c3 with c7' test

 The list of conflicted paths shown in the editor while concluding a
 conflicted merge was shown above the scissors line when the
 clean-up mode is set to "scissors", even though it was commented
 out just like the list of updated paths and other information to
 help the user explain the merge better.

 Will cook in 'next'.


* aw/pretty-trailers (2018-12-09) 7 commits
 - pretty: add support for separator option in %(trailers)
 - strbuf: separate callback for strbuf_expand:ing literals
 - pretty: add support for "valueonly" option in %(trailers)
 - pretty: allow showing specific trailers
 - pretty: single return path in %(trailers) handling
 - pretty: allow %(trailers) options with explicit value
 - doc: group pretty-format.txt placeholders descriptions

 The %(trailers) formatter in "git log --format=..."  now allows to
 optionally pick trailers selectively by keyword, show only values,
 etc.

 How's the doneness of this one?


* nd/attr-pathspec-in-tree-walk (2018-11-19) 5 commits
 - tree-walk: support :(attr) matching
 - dir.c: move, rename and export match_attrs()
 - pathspec.h: clean up "extern" in function declarations
 - tree-walk.c: make tree_entry_interesting() take an index
 - tree.c: make read_tree*() take 'struct repository *'

 The traversal over tree objects has learned to honor
 ":(attr:label)" pathspec match, which has been implemented only for
 enumerating paths on the filesystem.

 Will merge to 'next'.


* ab/commit-graph-progress-fix (2018-11-20) 1 commit
 - commit-graph: split up close_reachable() progress output

 Will merge to 'next'.


* jn/unknown-index-extensions (2018-11-21) 2 commits
 - index: offer advice for unknown index extensions
 - index: do not warn about unrecognized extensions

 A bit too alarming warning given when unknown index extensions
 exist is getting revamped.

 Expecting a reroll.


* en/fast-export-import (2018-11-17) 11 commits
  (merged to 'next' on 2018-11-18 at 87bbbffc95)
 + fast-export: add a --show-original-ids option to show original names
 + fast-import: remove unmaintained duplicate documentation
 + fast-export: add --reference-excluded-parents option
 + fast-export: ensure we export requested refs
 + fast-export: when using paths, avoid corrupt stream with non-existent mark
 + fast-export: move commit rewriting logic into a function for reuse
 + fast-export: avoid dying when filtering by paths and old tags exist
 + fast-export: use value from correct enum
 + git-fast-export.txt: clarify misleading documentation about rev-list args
 + git-fast-import.txt: fix documentation for --quiet option
 + fast-export: convert sha1 to oid

 Small fixes and features for fast-export and fast-import, mostly on
 the fast-export side.

 Will cook in 'next'.


* nd/checkout-dwim-fix (2018-11-14) 1 commit
  (merged to 'next' on 2018-11-18 at 3d714e7719)
 + checkout: disambiguate dwim tracking branches and local files

 "git checkout frotz" (without any double-dash) avoids ambiguity by
 making sure 'frotz' cannot be interpreted as a revision and as a
 path at the same time.  This safety has been updated to check also
 a unique remote-tracking branch 'frotz' in a remote, when dwimming
 to create a local branch 'frotz' out of a remote-tracking branch
 'frotz' from a remote.

 Will cook in 'next'.


* nd/checkout-noisy (2018-11-20) 2 commits
 - t0027: squelch checkout path run outside test_expect_* block
 - checkout: print something when checking out paths

 "git checkout [<tree-ish>] path..." learned to report the number of
 paths that have been checked out of the index or the tree-ish,
 which gives it the same degree of noisy-ness as the case in which
 the command checks out a branch.

 Will merge to 'next'.


* sg/clone-initial-fetch-configuration (2018-11-16) 3 commits
  (merged to 'next' on 2018-11-18 at cae0f3985b)
 + Documentation/clone: document ignored configuration variables
 + clone: respect additional configured fetch refspecs during initial fetch
 + clone: use a more appropriate variable name for the default refspec

 Refspecs configured with "git -c var=val clone" did not propagate
 to the resulting repository, which has been corrected.

 Will cook in 'next'.


* en/rebase-merge-on-sequencer (2018-11-08) 2 commits
 - rebase: implement --merge via git-rebase--interactive
 - git-rebase, sequencer: extend --quiet option for the interactive machinery

 "git rebase --merge" as been reimplemented by reusing the internal
 machinery used for "git rebase -i".

 Expecting a reroll.
 cf. <CABPp-BF8RupyfP69iqAVTXxEhBGyzVd-wUgp3y0pf+CbBFAQeg@mail.gmail.com>


* fc/http-version (2018-11-09) 1 commit
  (merged to 'next' on 2018-11-18 at 42f5155095)
 + http: add support selecting http version

 The "http.version" configuration variable can be used with recent
 enough cURL library to force the version of HTTP used to talk when
 fetching and pushing.

 Will cook in 'next'.


* dl/remote-save-to-push (2018-11-13) 1 commit
 - remote: add --save-to-push option to git remote set-url

 "git remote set-url" learned a new option that moves existing value
 of the URL field to pushURL field of the remote before replacing
 the URL field with a new value.

 I am personally not yet quite convinced if this is worth pursuing.


* jk/loose-object-cache (2018-11-24) 10 commits
  (merged to 'next' on 2018-11-24 at 5f4f22707d)
 + odb_load_loose_cache: fix strbuf leak
  (merged to 'next' on 2018-11-18 at 276691a21b)
 + fetch-pack: drop custom loose object cache
 + sha1-file: use loose object cache for quick existence check
 + object-store: provide helpers for loose_objects_cache
 + sha1-file: use an object_directory for the main object dir
 + handle alternates paths the same as the main object dir
 + sha1_file_name(): overwrite buffer instead of appending
 + rename "alternate_object_database" to "object_directory"
 + submodule--helper: prefer strip_suffix() to ends_with()
 + fsck: do not reuse child_process structs

 Code clean-up with optimization for the codepath that checks
 (non-)existence of loose objects.

 Will cook in 'next'.


* js/protocol-advertise-multi (2018-11-17) 1 commit
 - protocol: advertise multiple supported versions

 The transport layer has been updated so that the protocol version
 used can be negotiated between the parties, by the initiator
 listing the protocol versions it is willing to talk, and the other
 side choosing from one of them.

 How's the doneness of this one?


* js/smart-http-detect-remote-error (2018-11-17) 3 commits
  (merged to 'next' on 2018-11-18 at 5c6edfcb85)
 + remote-curl: die on server-side errors
 + remote-curl: tighten "version 2" check for smart-http
 + remote-curl: refactor smart-http discovery

 Some errors from the other side coming over smart HTTP transport
 were not noticed, which has been corrected.

 Will cook in 'next'.


* nb/branch-show-other-worktrees-head (2018-11-12) 2 commits
 - branch: mark and colorize a branch differently if it is checked out in a linked worktree
 - ref-filter: add worktree atom

 "git branch --list" learned to show branches that are checked out
 in other worktrees connected to the same repository prefixed with
 '+', similar to the way the currently checked out branch is shown
 with '*' in front.

 Expecting a reroll.


* nd/the-index (2018-11-12) 22 commits
  (merged to 'next' on 2018-11-18 at 73d1d8594e)
 + rebase-interactive.c: remove the_repository references
 + rerere.c: remove the_repository references
 + pack-*.c: remove the_repository references
 + pack-check.c: remove the_repository references
 + notes-cache.c: remove the_repository references
 + line-log.c: remove the_repository reference
 + diff-lib.c: remove the_repository references
 + delta-islands.c: remove the_repository references
 + cache-tree.c: remove the_repository references
 + bundle.c: remove the_repository references
 + branch.c: remove the_repository reference
 + bisect.c: remove the_repository reference
 + blame.c: remove implicit dependency the_repository
 + sequencer.c: remove implicit dependency on the_repository
 + sequencer.c: remove implicit dependency on the_index
 + transport.c: remove implicit dependency on the_index
 + notes-merge.c: remove implicit dependency the_repository
 + notes-merge.c: remove implicit dependency on the_index
 + list-objects.c: reduce the_repository references
 + list-objects-filter.c: remove implicit dependency on the_index
 + wt-status.c: remove implicit dependency the_repository
 + wt-status.c: remove implicit dependency on the_index

 More codepaths become aware of working with in-core repository
 instance other than the default "the_repository".

 Will cook in 'next'.


* ot/ref-filter-object-info (2018-11-24) 6 commits
  (merged to 'next' on 2018-11-24 at f8505762e3)
 + ref-filter: replace unportable `%lld` format with %PRIdMAX
  (merged to 'next' on 2018-11-18 at ad4c086678)
 + ref-filter: add docs for new options
 + ref-filter: add tests for deltabase
 + ref-filter: add deltabase option
 + ref-filter: add tests for objectsize:disk
 + ref-filter: add objectsize:disk option

 The "--format=<placeholder>" option of for-each-ref, branch and tag
 learned to show a few more traits of objects that can be learned by
 the object_info API.

 Will cook in 'next'.


* sb/diff-color-moved-config-option-fixup (2018-11-14) 1 commit
 - diff: align move detection error handling with other options

 Minor inconsistency fix.

 Will merge to 'next'.


* ab/push-dwim-dst (2018-11-14) 7 commits
  (merged to 'next' on 2018-11-18 at 36567023be)
 + push doc: document the DWYM behavior pushing to unqualified <dst>
 + push: test that <src> doesn't DWYM if <dst> is unqualified
 + push: add an advice on unqualified <dst> push
 + push: move unqualified refname error into a function
 + push: improve the error shown on unqualified <dst> push
 + i18n: remote.c: mark error(...) messages for translation
 + remote.c: add braces in anticipation of a follow-up change

 "git push $there $src:$dst" rejects when $dst is not a fully
 qualified refname and not clear what the end user meant.  The
 codepath has been taught to give a clearer error message, and also
 guess where the push should go by taking the type of the pushed
 object into account (e.g. a tag object would want to go under
 refs/tags/).

 Will cook in 'next'.


* md/list-lazy-objects-fix (2018-12-06) 1 commit
 - list-objects.c: don't segfault for missing cmdline objects

 "git rev-list --exclude-promissor-objects" had to take an object
 that does not exist locally (and is lazily available) from the
 command line without barfing, but the code dereferenced NULL.

 Will merge to 'next'.


* nd/i18n (2018-11-12) 16 commits
  (merged to 'next' on 2018-11-18 at 5215bd2f7d)
 + fsck: mark strings for translation
 + fsck: reduce word legos to help i18n
 + parse-options.c: mark more strings for translation
 + parse-options.c: turn some die() to BUG()
 + parse-options: replace opterror() with optname()
 + repack: mark more strings for translation
 + remote.c: mark messages for translation
 + remote.c: turn some error() or die() to BUG()
 + reflog: mark strings for translation
 + read-cache.c: add missing colon separators
 + read-cache.c: mark more strings for translation
 + read-cache.c: turn die("internal error") to BUG()
 + attr.c: mark more string for translation
 + archive.c: mark more strings for translation
 + alias.c: mark split_cmdline_strerror() strings for translation
 + git.c: mark more strings for translation

 More _("i18n") markings.

 Will cook in 'next'.


* sb/more-repo-in-api (2018-11-14) 23 commits
  (merged to 'next' on 2018-11-19 at e5d2a129da)
 + t/helper/test-repository: celebrate independence from the_repository
 + path.h: make REPO_GIT_PATH_FUNC repository agnostic
 + commit: prepare free_commit_buffer and release_commit_memory for any repo
 + commit-graph: convert remaining functions to handle any repo
 + submodule: don't add submodule as odb for push
 + submodule: use submodule repos for object lookup
 + pretty: prepare format_commit_message to handle arbitrary repositories
 + commit: prepare logmsg_reencode to handle arbitrary repositories
 + commit: prepare repo_unuse_commit_buffer to handle any repo
 + commit: prepare get_commit_buffer to handle any repo
 + commit-reach: prepare in_merge_bases[_many] to handle any repo
 + commit-reach: prepare get_merge_bases to handle any repo
 + commit-reach.c: allow get_merge_bases_many_0 to handle any repo
 + commit-reach.c: allow remove_redundant to handle any repo
 + commit-reach.c: allow merge_bases_many to handle any repo
 + commit-reach.c: allow paint_down_to_common to handle any repo
 + commit: allow parse_commit* to handle any repo
 + object: parse_object to honor its repository argument
 + object-store: prepare has_{sha1, object}_file to handle any repo
 + object-store: prepare read_object_file to deal with any repo
 + object-store: allow read_object_file_extended to read from any repo
 + packfile: allow has_packed_and_bad to handle arbitrary repositories
 + sha1_file: allow read_object to read objects in arbitrary repositories
 (this branch is used by jt/get-reference-with-commit-graph.)

 The in-core repository instances are passed through more codepaths.

 Will cook in 'next'.
 cf. <20181115221254.45373-1-jonathantanmy@google.com>


* en/merge-path-collision (2018-12-01) 11 commits
  (merged to 'next' on 2018-12-01 at 24492e61f1)
 + t6036: avoid non-portable "cp -a"
  (merged to 'next' on 2018-11-18 at 3ec9286e0b)
 + merge-recursive: combine error handling
 + t6036, t6043: increase code coverage for file collision handling
 + merge-recursive: improve rename/rename(1to2)/add[/add] handling
 + merge-recursive: use handle_file_collision for add/add conflicts
 + merge-recursive: improve handling for rename/rename(2to1) conflicts
 + merge-recursive: fix rename/add conflict handling
 + merge-recursive: new function for better colliding conflict resolutions
 + merge-recursive: increase marker length with depth of recursion
 + t6036, t6042: testcases for rename collision of already conflicting files
 + t6042: add tests for consistency in file collision conflict handling

 Updates for corner cases in merge-recursive.

 Will cook in 'next'.


* sd/stash-wo-user-name (2018-11-19) 1 commit
  (merged to 'next' on 2018-11-19 at 0838b091ea)
 + stash: tolerate missing user identity

 A properly configured username/email is required under
 user.useConfigOnly in order to create commits; now "git stash"
 (even though it creates commit objects to represent stash entries)
 command is excempt from the requirement.

 Will cook in 'next'.


* bc/sha-256 (2018-11-14) 12 commits
 - hash: add an SHA-256 implementation using OpenSSL
 - sha256: add an SHA-256 implementation using libgcrypt
 - Add a base implementation of SHA-256 support
 - commit-graph: convert to using the_hash_algo
 - t/helper: add a test helper to compute hash speed
 - sha1-file: add a constant for hash block size
 - t: make the sha1 test-tool helper generic
 - t: add basic tests for our SHA-1 implementation
 - cache: make hashcmp and hasheq work with larger hashes
 - hex: introduce functions to print arbitrary hashes
 - sha1-file: provide functions to look up hash algorithms
 - sha1-file: rename algorithm to "sha1"

 Add sha-256 hash and plug it through the code to allow building Git
 with the "NewHash".


* js/vsts-ci (2018-10-16) 13 commits
 . travis: fix skipping tagged releases
 . README: add a build badge (status of the Azure Pipelines build)
 . tests: record more stderr with --write-junit-xml in case of failure
 . tests: include detailed trace logs with --write-junit-xml upon failure
 . git-p4: use `test_atexit` to kill the daemon
 . git-daemon: use `test_atexit` in the tests
 . tests: introduce `test_atexit`
 . ci: add a build definition for Azure DevOps
 . ci/lib.sh: add support for Azure Pipelines
 . tests: optionally write results as JUnit-style .xml
 . test-date: add a subcommand to measure times in shell scripts
 . ci/lib.sh: encapsulate Travis-specific things
 . ci: rename the library of common functions

 Prepare to run test suite on Azure DevOps.

 Ejected out of 'pu', as doing so seems to help other topics get
 tested at TravisCI.

 https://travis-ci.org/git/git/builds/452713184 is a sample of a
 build whose tests on 4 hang (with this series in).  Ejecting it
 gave us https://travis-ci.org/git/git/builds/452778963 which still
 shows breakages from other topics not yet in 'next', but at least
 the tests do not stall.


* du/branch-show-current (2018-10-26) 1 commit
 - branch: introduce --show-current display option

 "git branch" learned a new subcommand "--show-current".

 I am personally not yet quite convinced if this is worth pursuing.


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


* ag/sequencer-reduce-rewriting-todo (2018-11-12) 16 commits
 . rebase--interactive: move transform_todo_file() to rebase--interactive.c
 . sequencer: fix a call to error() in transform_todo_file()
 . sequencer: use edit_todo_list() in complete_action()
 . rebase-interactive: rewrite edit_todo_list() to handle the initial edit
 . rebase-interactive: append_todo_help() changes
 . rebase-interactive: use todo_list_write_to_file() in edit_todo_list()
 . sequencer: refactor skip_unnecessary_picks() to work on a todo_list
 . sequencer: change complete_action() to use the refactored functions
 . sequencer: make sequencer_make_script() write its script to a strbuf
 . sequencer: refactor rearrange_squash() to work on a todo_list
 . sequencer: refactor sequencer_add_exec_commands() to work on a todo_list
 . sequencer: refactor check_todo_list() to work on a todo_list
 . sequencer: introduce todo_list_write_to_file()
 . sequencer: refactor transform_todos() to work on a todo_list
 . sequencer: make the todo_list structure public
 . sequencer: changes in parse_insn_buffer()

 The scripted version of "git rebase -i" wrote and rewrote the todo
 list many times during a single step of its operation, and the
 recent C-rewrite made a faithful conversion of the logic to C.  The
 implementation has been updated to carry necessary information
 around in-core to avoid rewriting the same file over and over
 unnecessarily.

 With too many topics in-flight that touch sequencer and rebaser,
 this need to wait giving precedence to other topics that fix bugs.


* sb/submodule-recursive-fetch-gets-the-tip (2018-12-09) 9 commits
 - fetch: ensure submodule objects fetched
 - submodule.c: fetch in submodules git directory instead of in worktree
 - submodule: migrate get_next_submodule to use repository structs
 - repository: repo_submodule_init to take a submodule struct
 - submodule: store OIDs in changed_submodule_names
 - submodule.c: tighten scope of changed_submodule_names struct
 - submodule.c: sort changed_submodule_names before searching it
 - submodule.c: fix indentation
 - sha1-array: provide oid_array_filter

 "git fetch --recurse-submodules" may not fetch the necessary commit
 that is bound to the superproject, which is getting corrected.

 Ready?


* js/add-i-coalesce-after-editing-hunk (2018-08-28) 1 commit
 - add -p: coalesce hunks before testing applicability

 Applicability check after a patch is edited in a "git add -i/p"
 session has been improved.

 Will hold.
 cf. <e5b2900a-0558-d3bf-8ea1-d526b078bbc2@talktalk.net>


* ps/stash-in-c (2018-11-26) 22 commits
 . stash: replace all `write-tree` child processes with API calls
 . stash: optimize `get_untracked_files()` and `check_changes()`
 . stash: convert `stash--helper.c` into `stash.c`
 . stash: convert save to builtin
 . stash: make push -q quiet
 . stash: convert push to builtin
 . stash: convert create to builtin
 . stash: convert store to builtin
 . stash: convert show to builtin
 . stash: convert list to builtin
 . stash: convert pop to builtin
 . stash: convert branch to builtin
 . stash: convert drop and clear to builtin
 . stash: convert apply to builtin
 . stash: mention options in `show` synopsis
 . stash: add tests for `git stash show` config
 . stash: rename test cases to be more descriptive
 . t3903: modernize style
 . stash: improve option parsing test coverage
 . strbuf.c: add `strbuf_insertf()` and `strbuf_vinsertf()`
 . strbuf.c: add `strbuf_join_argv()`
 . sha1-name.c: add `get_oidf()` which acts like `get_oid()`

 "git stash" rewritten in C.

 Expecting a reroll, probably on top of the sd/stash-wo-user-name
 topic after it stabilizes, with an escape hatch like the one in
 "rebase in C".


* pw/add-p-select (2018-07-26) 4 commits
 - add -p: optimize line selection for short hunks
 - add -p: allow line selection to be inverted
 - add -p: select modified lines correctly
 - add -p: select individual hunk lines

 "git add -p" interactive interface learned to let users choose
 individual added/removed lines to be used in the operation, instead
 of accepting or rejecting a whole hunk.

 Will discard.
 No further feedbacks on the topic for quite some time.

 cf. <d622a95b-7302-43d4-4ec9-b2cf3388c653@talktalk.net>
 I found the feature to be hard to explain, and may result in more
 end-user complaints, but let's see.

--------------------------------------------------
[Discarded]

* ab/reject-alias-loop (2018-10-19) 1 commit
  (merged to 'next' on 2018-10-26 at bc213f1bef)
 + alias: detect loops in mixed execution mode

 Two (or more) aliases that mutually refer to each other can form an
 infinite loop; we now attempt to notice and stop.

 Discarded.
 Reverted out of 'next'.
 cf. <87sh0slvxm.fsf@evledraar.gmail.com>


* gl/bundle-unlock-before-aborting (2018-11-14) 1 commit
 . bundle: rollback lock file while refusing to create an empty bundle

 Superseded by jk/close-duped-fd-before-unlock-for-bundle


* js/remote-archive-v2 (2018-09-28) 4 commits
  (merged to 'next' on 2018-10-12 at 5f34377f60)
 + archive: allow archive over HTTP(S) with proto v2
 + archive: implement protocol v2 archive command
 + archive: use packet_reader for communications
 + archive: follow test standards around assertions

 The original implementation of "git archive --remote" more or less
 bypassed the transport layer and did not work over http(s).  The
 version 2 of the protocol is defined to allow going over http(s) as
 well as Git native transport.

 Retracted; reverted out of next.
 cf. <20181114195142.GI126896@google.com>


* ab/format-patch-rangediff-not-stat (2018-11-24) 1 commit
  (merged to 'next' on 2018-11-26 at d9c84916b3)
 + format-patch: don't include --stat with --range-diff output

 The "--rangediff" option recently added to "format-patch"
 interspersed a bogus and useless "--stat" information by mistake,
 which is being corrected.

 Reverted out of 'next'.


* jc/postpone-rebase-in-c (2018-11-26) 1 commit
  (merged to 'next' on 2018-11-26 at c6ae45110f)
 + rebase: mark the C reimplementation as an experimental opt-in feature

 People seem to be still finding latent bugs in the "rebase in C"
 reimplementation.  For the upcoming release, use the scripted
 version by default and adjust the documentation accordingly.

 Reverted out of 'next'.

Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Denton Liu]

On Sun, Dec 09, 2018 at 05:42:27PM +0900, Junio C Hamano wrote:
> * dl/merge-cleanup-scissors-fix (2018-11-21) 2 commits
>   (merged to 'next' on 2018-11-21 at 217be06acb)
>  + merge: add scissors line on merge conflict
>  + t7600: clean up 'merge --squash c3 with c7' test
> 
>  The list of conflicted paths shown in the editor while concluding a
>  conflicted merge was shown above the scissors line when the
>  clean-up mode is set to "scissors", even though it was commented
>  out just like the list of updated paths and other information to
>  help the user explain the merge better.
> 
>  Will cook in 'next'.

From our discussion[1], expect a reroll with the ability to do scissors
cleanup in messages generated by git-merge. Unfortunately, it'll be a
couple of weeks because of finals season.

> 
> * dl/remote-save-to-push (2018-11-13) 1 commit
>  - remote: add --save-to-push option to git remote set-url
> 
>  "git remote set-url" learned a new option that moves existing value
>  of the URL field to pushURL field of the remote before replacing
>  the URL field with a new value.
> 
>  I am personally not yet quite convinced if this is worth pursuing.

Any way I could convince you otherwise? I guess this could be rolled
into a helper script but it'd be very useful to have the behaviour
standardised into the actual remote builtin.

[1]: https://public-inbox.org/git/xmqqin0n44dv.fsf@gitster-ct.c.googlers.com/

pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Johannes Schindelin]

Hi Junio,

On Sun, 9 Dec 2018, Junio C Hamano wrote:

> * pw/add-p-select (2018-07-26) 4 commits
>  - add -p: optimize line selection for short hunks
>  - add -p: allow line selection to be inverted
>  - add -p: select modified lines correctly
>  - add -p: select individual hunk lines
> 
>  "git add -p" interactive interface learned to let users choose
>  individual added/removed lines to be used in the operation, instead
>  of accepting or rejecting a whole hunk.
> 
>  Will discard.
>  No further feedbacks on the topic for quite some time.

That is not quite true. I did comment that this feature (which I take as
being inspired by Git GUI's "Stage Selected Line"), and thought that it
would be useful.

I could imagine, however, that it would make sense for `git add -p` to
imitate that feature more closely: by allowing to stage a single line and
then presenting the current hunk (re-computed) again.

Ciao,
Dscho

Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Junio C Hamano]

Denton Liu <liu.denton@gmail.com> writes:

> On Sun, Dec 09, 2018 at 05:42:27PM +0900, Junio C Hamano wrote:
>> * dl/merge-cleanup-scissors-fix (2018-11-21) 2 commits
>>   (merged to 'next' on 2018-11-21 at 217be06acb)
>>  + merge: add scissors line on merge conflict
>>  + t7600: clean up 'merge --squash c3 with c7' test
>> 
>>  The list of conflicted paths shown in the editor while concluding a
>>  conflicted merge was shown above the scissors line when the
>>  clean-up mode is set to "scissors", even though it was commented
>>  out just like the list of updated paths and other information to
>>  help the user explain the merge better.
>> 
>>  Will cook in 'next'.
>
> From our discussion[1], expect a reroll with the ability to do scissors
> cleanup in messages generated by git-merge. Unfortunately, it'll be a
> couple of weeks because of finals season.

OK, I'd imagine that it would be cleaner to do so as a fresh series,
instead of incremental updates on top of these two, so let's plan to
eject what we have in 'next' when it happens.  Thanks for a heads-up.

>> * dl/remote-save-to-push (2018-11-13) 1 commit
>>  - remote: add --save-to-push option to git remote set-url
>> 
>>  "git remote set-url" learned a new option that moves existing value
>>  of the URL field to pushURL field of the remote before replacing
>>  the URL field with a new value.
>> 
>>  I am personally not yet quite convinced if this is worth pursuing.
>
> Any way I could convince you otherwise?

I think v3 (which we see above) describes what it wants to do
clearly enough and implements what it wants to do cleanly.  I do not
think the patch itself has much room for further improvement.

When I re-read the final patch and all the earlier comments I made
in the thread that began at [*1*], I still do not see in what
practical workflow and usecase the users would find the feature this
change adds useful.  

For each new feature, I want a story we can sell it to the users:
"if your workflow is like this or that, you would find yourself
wanting to do this, which was (impossible|cumbersome) to do before;
with this new thing, you can".

And the "story" is not "If you have remote.$name.url and want to
move its value to remote.$name.pushurl while setting the former to a
new value, then..."  I want to know why the user gets in such a
situation in the first place.

To be helped by the feature, the user

 (1) must first have a remote.$name.url (but not remote.$name.pushurl)

 (2) that URL must also be usable for pushing

 (3) and then has another URL that can be used for fetching

 (4) and somehow that new URL is more suitable for fetching than the
     original one.

When all of the above holds, then "set-url --save-to-push" can be
used to move the original URL that can be used for both fetching and
pushing to remote.$name.pushurl and set remote.$name.url to the new
value with a single command.  But is that a sensible situation to be
in the first place?

I guess it would help the readers if the documentation (or proposed
log message) were more explicit that this is to help the project
originator more than the project followers, perhaps.  My working
assumption during the review discussion on this patch has been that
there are orders-of-magnitude many project followers who start from
fetching and locally tweaking without ever publishing than those who
start to pushing to a project from day one of joining, or the day
they themselves initiated the project.  And for these majority
"followers", the first URL is often the one to fetch, which may not
necessarily be usable for pushing, and that URL is advertised for
the wider general public as the most suitable URL for fetching the
project's source.  So to these people, neither (2) or (4) would
hold.

But for project initiators and those joining a project with write
access from day one, the story may be a bit different.  They may
start with a single URL that can be used for both fetching and
pushing, which means (2) would hold for them, unlike for the
majority of users.

I am still not sure what a good example situation is that makes (4)
hold, though.  Perhaps you originally had a R/W URL that always
require authentication, but now you want to use an anonymous R/O URL
for your fetch traffic without having to authenticate?  If there is
a model situation to make all of these four hold, perhaps it can be
added somewhere to help users who would find the new feature useful
discover it.

Without that, I remain unconvinced.

Thanks.


[Reference]

*1*  https://public-inbox.org/git/1d1b0fe85ddd89cf8172e730e8886d5b4a9ea7eb.1540627720.git.liu.denton@gmail.com/

Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Denton Liu]

On Mon, Dec 10, 2018 at 12:21:05PM +0900, Junio C Hamano wrote:
> I think v3 (which we see above) describes what it wants to do
> clearly enough and implements what it wants to do cleanly.  I do not
> think the patch itself has much room for further improvement.
> 
> When I re-read the final patch and all the earlier comments I made
> in the thread that began at [*1*], I still do not see in what
> practical workflow and usecase the users would find the feature this
> change adds useful.  
> 
> For each new feature, I want a story we can sell it to the users:
> "if your workflow is like this or that, you would find yourself
> wanting to do this, which was (impossible|cumbersome) to do before;
> with this new thing, you can".
> 
> And the "story" is not "If you have remote.$name.url and want to
> move its value to remote.$name.pushurl while setting the former to a
> new value, then..."  I want to know why the user gets in such a
> situation in the first place.
> 
> To be helped by the feature, the user
> 
>  (1) must first have a remote.$name.url (but not remote.$name.pushurl)
> 
>  (2) that URL must also be usable for pushing
> 
>  (3) and then has another URL that can be used for fetching
> 
>  (4) and somehow that new URL is more suitable for fetching than the
>      original one.
> 
> When all of the above holds, then "set-url --save-to-push" can be
> used to move the original URL that can be used for both fetching and
> pushing to remote.$name.pushurl and set remote.$name.url to the new
> value with a single command.  But is that a sensible situation to be
> in the first place?

The following is the story that led to me writing the feature in the
first place:

I have a project that's been developed on my own machine. I want to
deploy it onto a server to test, so I use SSH key forwarding and clone
the project with the SSH URL onto the server. After fixing some small
bugs, I'll push the changes directly from the server up. 

Now that the server is running, I only touch the repo on the server
occasionally. I want to pull updates from the main repository without
necessarily having to use SSH key forwarding because I might be
forgetful and forget to start ssh-agent or I might have someone else
administer the server who doesn't have key-access to the repository.
However, I also don't want to get rid of my ability to push over SSH so,
in this case, I'd run 
`git remote set-url --save-to-push origin <HTTPS_URL>`.

Although it's definitely not an every day activity, I've run into the
use case a few times where having this ability would definitely be
useful.

> 
> I guess it would help the readers if the documentation (or proposed
> log message) were more explicit that this is to help the project
> originator more than the project followers, perhaps.  My working
> assumption during the review discussion on this patch has been that
> there are orders-of-magnitude many project followers who start from
> fetching and locally tweaking without ever publishing than those who
> start to pushing to a project from day one of joining, or the day
> they themselves initiated the project.  And for these majority
> "followers", the first URL is often the one to fetch, which may not
> necessarily be usable for pushing, and that URL is advertised for
> the wider general public as the most suitable URL for fetching the
> project's source.  So to these people, neither (2) or (4) would
> hold.
> 
> But for project initiators and those joining a project with write
> access from day one, the story may be a bit different.  They may
> start with a single URL that can be used for both fetching and
> pushing, which means (2) would hold for them, unlike for the
> majority of users.
> 
> I am still not sure what a good example situation is that makes (4)
> hold, though.  Perhaps you originally had a R/W URL that always
> require authentication, but now you want to use an anonymous R/O URL
> for your fetch traffic without having to authenticate?  If there is
> a model situation to make all of these four hold, perhaps it can be
> added somewhere to help users who would find the new feature useful
> discover it.

If the above makes sense to you, I can try to distill the use-case down
to its essence and include it documentation for the patch.

> 
> Without that, I remain unconvinced.
> 
> Thanks.
> 
> 
> [Reference]
> 
> *1*  https://public-inbox.org/git/1d1b0fe85ddd89cf8172e730e8886d5b4a9ea7eb.1540627720.git.liu.denton@gmail.com/

Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Junio C Hamano]

Denton Liu <liu.denton@gmail.com> writes:

> On Mon, Dec 10, 2018 at 12:21:05PM +0900, Junio C Hamano wrote:
>
>> And the "story" is not "If you have remote.$name.url and want to
>> move its value to remote.$name.pushurl while setting the former to a
>> new value, then..."  I want to know why the user gets in such a
>> situation in the first place.
> ...
> The following is the story that led to me writing the feature in the
> first place:
> ...

OK, so in essense, it is quite similar to the following,

>> ....  Perhaps you originally had a R/W URL that always
>> require authentication, but now you want to use an anonymous R/O URL
>> for your fetch traffic without having to authenticate?  If there is
>> a model situation to make all of these four hold, perhaps it can be
>> added somewhere to help users who would find the new feature useful
>> discover it.

i.e.

	You may have started your interaction with the repository
	with a single authenticated URL that can be used for both
	fetching and pushing, but over time you may have become sick
	of having to authenticate only to fetch.  In such a case,
	you can feed an unauthenticated/anonymous fetch URL to
	set-url with this option, so that the authenticated URL that
	you have been using for pushing becomes the pushURL, and the
	new, unauthenticated/anonymous URL will be used for
	fetching.

With something like that in the documentation, I think the users
won't be puzzled by a feature that is seemingly a bit too niche, I
would think.

Thanks.

Re: pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Phillip Wood]

Hi Dscho

On 09/12/2018 20:31, Johannes Schindelin wrote:
> Hi Junio,
> 
> On Sun, 9 Dec 2018, Junio C Hamano wrote:
> 
>> * pw/add-p-select (2018-07-26) 4 commits
>>   - add -p: optimize line selection for short hunks
>>   - add -p: allow line selection to be inverted
>>   - add -p: select modified lines correctly
>>   - add -p: select individual hunk lines
>>
>>   "git add -p" interactive interface learned to let users choose
>>   individual added/removed lines to be used in the operation, instead
>>   of accepting or rejecting a whole hunk.
>>
>>   Will discard.
>>   No further feedbacks on the topic for quite some time.
> 
> That is not quite true. I did comment that this feature

Sorry I meant to reply to that comment but never got round to it.

> (which I take as
> being inspired by Git GUI's "Stage Selected Line"),

not particularly, I don't use git gui I just wanted a way to easily 
stage a subset of lines without editing the hunk.

> and thought that it would be useful.
> 
> I could imagine, however, that it would make sense for `git add -p` to
> imitate that feature more closely: by allowing to stage a single line and
> then presenting the current hunk (re-computed) again.

that sounds like it would be quite tedious to stage more than a couple 
of lines, and it could be awkward to get it to stage modified lines 
correctly (While I was writing the feature I tried git gui, I think it 
is supposed to be able to stage modified lines correctly but I never 
persuaded it to do it for me. I also tried gitg, tig and hg commit -i 
but I couldn't get them to do modified lines either)

I'll try and re-roll in the New Year, when does the outreachy project 
for converting add -i start? - it would be good to try and get this 
pinned down before then.

Best Wishes

Phillip
> Ciao,
> Dscho
> 

Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Josh Steadmon]

On 2018.12.09 17:42, Junio C Hamano wrote:
> * js/protocol-advertise-multi (2018-11-17) 1 commit
>  - protocol: advertise multiple supported versions
> 
>  The transport layer has been updated so that the protocol version
>  used can be negotiated between the parties, by the initiator
>  listing the protocol versions it is willing to talk, and the other
>  side choosing from one of them.
> 
>  How's the doneness of this one?

I'm not sure if you're asking me specifically or the list in general,
but I haven't heard any complaints about this, and there are no
outstanding requests on the review thread.


> * js/smart-http-detect-remote-error (2018-11-17) 3 commits
>   (merged to 'next' on 2018-11-18 at 5c6edfcb85)
>  + remote-curl: die on server-side errors
>  + remote-curl: tighten "version 2" check for smart-http
>  + remote-curl: refactor smart-http discovery
> 
>  Some errors from the other side coming over smart HTTP transport
>  were not noticed, which has been corrected.
> 
>  Will cook in 'next'.

Masaya had a series that addresses this as well:
https://public-inbox.org/git/20181127045301.103807-1-masayasuzuki@google.com/

To combine these, we'd want to drop the diff to remote-curl.c in the
final patch of this series.

Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Elijah Newren]

On Sun, Dec 9, 2018 at 12:42 AM Junio C Hamano <gitster@pobox.com> wrote:

> Git 2.20 has been tagged.  I'd expect that we would slow down to see
> how stable it is and queue only the brown-paper-bag fixes for a week
> or so, before opening the tree for the next cycle, rewinding the tip
> of 'next', etc.

Does this mean you'd prefer we continue to wait a little longer before
sending in new series and re-rolls, or just that you are managing
expectations about when they might be queued?

(Just curious whether I should submit my rebase-merge-on-sequencer
re-roll or continue waiting.  I'm happy to do whatever is more
convenient for others.)

Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Ævar Arnfjörð Bjarmason]

On Mon, Dec 10 2018, Elijah Newren wrote:

> On Sun, Dec 9, 2018 at 12:42 AM Junio C Hamano <gitster@pobox.com> wrote:
>
>> Git 2.20 has been tagged.  I'd expect that we would slow down to see
>> how stable it is and queue only the brown-paper-bag fixes for a week
>> or so, before opening the tree for the next cycle, rewinding the tip
>> of 'next', etc.
>
> Does this mean you'd prefer we continue to wait a little longer before
> sending in new series and re-rolls, or just that you are managing
> expectations about when they might be queued?
>
> (Just curious whether I should submit my rebase-merge-on-sequencer
> re-roll or continue waiting.  I'm happy to do whatever is more
> convenient for others.)

Related; Junio: I've submitted a few things in the last 2-3 weeks which
I knew weren't making it into 2.20, but I just wanted to kick out the
door as I had them ready. Things which are not noted in this "What's
Cooking".

I'm fine with re-submitting those once 2.21 picks up, but don't want to
needlessly spam if your plan is to circle around and pick up those
things you were (rightly) ignoring during the RC period.

Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Junio C Hamano]

Josh Steadmon <steadmon@google.com> writes:

> On 2018.12.09 17:42, Junio C Hamano wrote:
>> * js/protocol-advertise-multi (2018-11-17) 1 commit
>>  - protocol: advertise multiple supported versions
>> 
>>  The transport layer has been updated so that the protocol version
>>  used can be negotiated between the parties, by the initiator
>>  listing the protocol versions it is willing to talk, and the other
>>  side choosing from one of them.
>> 
>>  How's the doneness of this one?
>
> I'm not sure if you're asking me specifically or the list in general,
> but I haven't heard any complaints about this, and there are no
> outstanding requests on the review thread.

It is both but more of the latter ;-)  "I haven't seen any problem
reported, and all review comments have been addressed" by you is
also a welcome feedback.

>> * js/smart-http-detect-remote-error (2018-11-17) 3 commits
>>   (merged to 'next' on 2018-11-18 at 5c6edfcb85)
>>  + remote-curl: die on server-side errors
>>  + remote-curl: tighten "version 2" check for smart-http
>>  + remote-curl: refactor smart-http discovery
>> 
>>  Some errors from the other side coming over smart HTTP transport
>>  were not noticed, which has been corrected.
>> 
>>  Will cook in 'next'.
>
> Masaya had a series that addresses this as well:
> https://public-inbox.org/git/20181127045301.103807-1-masayasuzuki@google.com/
>
> To combine these, we'd want to drop the diff to remote-curl.c in the
> final patch of this series.

OK, I'll kick the topic out of 'next' when reopening the tree for
the next cycle.  Could you work with him to feed me the result of
combined effort to replace these three patches?  Thanks.

Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Junio C Hamano]

Elijah Newren <newren@gmail.com> writes:

> On Sun, Dec 9, 2018 at 12:42 AM Junio C Hamano <gitster@pobox.com> wrote:
>
>> Git 2.20 has been tagged.  I'd expect that we would slow down to see
>> how stable it is and queue only the brown-paper-bag fixes for a week
>> or so, before opening the tree for the next cycle, rewinding the tip
>> of 'next', etc.
>
> Does this mean you'd prefer we continue to wait a little longer before
> sending in new series and re-rolls, or just that you are managing
> expectations about when they might be queued?

More of the latter.  The best way to find bugs that matter in real
life is to use the software in the real project settings, i.e. you
guys work on your own topics using Git.  I'll keep reviewing and
commenting just like other reviewers, but the new patches won't come
close to 'next' (as I said elsewhere, being in 'pu' does not count
much---it is like getting bookmarked) in the meantime.

Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Related; Junio: I've submitted a few things in the last 2-3 weeks which
> I knew weren't making it into 2.20, but I just wanted to kick out the
> door as I had them ready. Things which are not noted in this "What's
> Cooking".
>
> I'm fine with re-submitting those once 2.21 picks up, but don't want to
> needlessly spam if your plan is to circle around and pick up those
> things you were (rightly) ignoring during the RC period.

Please consider it a time to get things reviewed by each other and a
chance to polish them before they even hit 'pu'.

Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Stefan Beller]

> * sb/more-repo-in-api (2018-11-14) 23 commits
>   (merged to 'next' on 2018-11-19 at e5d2a129da)
> [..]
>  The in-core repository instances are passed through more codepaths.
>
>  Will cook in 'next'.
>  cf. <20181115221254.45373-1-jonathantanmy@google.com>

Looking into that.

> * sb/submodule-recursive-fetch-gets-the-tip (2018-12-09) 9 commits
> [..]
>  "git fetch --recurse-submodules" may not fetch the necessary commit
>  that is bound to the superproject, which is getting corrected.
>
>  Ready?

I saw you picked up the latest iteration of the last patch at
https://public-inbox.org/git/20181206212655.145586-1-sbeller@google.com/
which has received no review comments, yet, and you seem to have
just taken it for replacement without looking closely.

I think it is ready, but I seem to be an optimist at times
when it comes to my own code. :-)

Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> I saw you picked up the latest iteration of the last patch at
> https://public-inbox.org/git/20181206212655.145586-1-sbeller@google.com/
> which has received no review comments, yet, and you seem to have
> just taken it for replacement without looking closely.

What's there in 'pu' does not even count as getting "picked up".
Near the tip of 'pu' outside 'next' is merely serving as a bookmark
so that I do not have to hunt around in the list archive after
people comment on the patches.

> I think it is ready, but I seem to be an optimist at times
> when it comes to my own code. :-)

Oh, who isn't?

Re: pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Johannes Schindelin]

Hi Phillip,

[Cc:ing Slavica, the Outreachy intern working on converting `add -i` to a
built-in]

On Mon, 10 Dec 2018, Phillip Wood wrote:

> On 09/12/2018 20:31, Johannes Schindelin wrote:
> > 
> > On Sun, 9 Dec 2018, Junio C Hamano wrote:
> > 
> > > * pw/add-p-select (2018-07-26) 4 commits
> > >   - add -p: optimize line selection for short hunks
> > >   - add -p: allow line selection to be inverted
> > >   - add -p: select modified lines correctly
> > >   - add -p: select individual hunk lines
> > >
> > >   "git add -p" interactive interface learned to let users choose
> > >   individual added/removed lines to be used in the operation, instead
> > >   of accepting or rejecting a whole hunk.
> > >
> > >   Will discard.
> > >   No further feedbacks on the topic for quite some time.
> > 
> > That is not quite true. I did comment that this feature
> 
> Sorry I meant to reply to that comment but never got round to it.

No worries. We're all busy down here.

> > (which I take as being inspired by Git GUI's "Stage Selected Line"),
> 
> not particularly, I don't use git gui I just wanted a way to easily
> stage a subset of lines without editing the hunk.

Okay. I used to use Git GUI quite a bit to stage individual lines, but
recently I tried to stay more in the terminal and used the `split` and
`edit` commands of `add -p` quite extensively. Wishing for an quicker way
to stage individual lines between all of my debug print statements.

> > and thought that it would be useful.
> > 
> > I could imagine, however, that it would make sense for `git add -p` to
> > imitate that feature more closely: by allowing to stage a single line
> > and then presenting the current hunk (re-computed) again.
> 
> that sounds like it would be quite tedious to stage more than a couple
> of lines,

It would be. But then, if you want to do anything slightly more
complicated than staging a hunk or a line, I personally prefer the `edit`
command *a lot*, as it lets me even split unrelated changes in the same
line into two commits.

> and it could be awkward to get it to stage modified lines correctly
> (While I was writing the feature I tried git gui, I think it is supposed
> to be able to stage modified lines correctly but I never persuaded it to
> do it for me. I also tried gitg, tig and hg commit -i but I couldn't get
> them to do modified lines either)

Git GUI works very reliably for me, but then, I have Git for Windows'
patched Git GUI at my finger tips (oh how I wish we had a Git GUI
maintainer again).

It should not be awkward to stage a single modified line at all.
Essentially, you take the hunk, strip out all `-` and `+` lines except the
one you want to stage, then stage that with `git apply --cached
--recount`, and then you simply re-generate that hunk.

> I'll try and re-roll in the New Year, when does the outreachy project
> for converting add -i start? - it would be good to try and get this
> pinned down before then.

Too late. Slavica started on December 4th, and you can even read about it
on their blog: https://slavicadj.github.io/blog/

Ciao,
Dscho

Re: pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Phillip Wood]

Hi Dscho and Slavica

On 11/12/2018 09:56, Johannes Schindelin wrote:
> Hi Phillip,
> 
> [Cc:ing Slavica, the Outreachy intern working on converting `add -i` to a
> built-in]
> 
> On Mon, 10 Dec 2018, Phillip Wood wrote:
> 
>> On 09/12/2018 20:31, Johannes Schindelin wrote:
>>>

<snip/>

>>> (which I take as being inspired by Git GUI's "Stage Selected Line"),
>>
>> not particularly, I don't use git gui I just wanted a way to easily
>> stage a subset of lines without editing the hunk.
> 
> Okay. I used to use Git GUI quite a bit to stage individual lines, but
> recently I tried to stay more in the terminal and used the `split` and
> `edit` commands of `add -p` quite extensively. Wishing for an quicker way
> to stage individual lines between all of my debug print statements.

Yes that's one of my main uses for selective staging as well

>>> and thought that it would be useful.
>>>
>>> I could imagine, however, that it would make sense for `git add -p` to
>>> imitate that feature more closely: by allowing to stage a single line
>>> and then presenting the current hunk (re-computed) again.
>>
>> that sounds like it would be quite tedious to stage more than a couple
>> of lines,
> 
> It would be. But then, if you want to do anything slightly more
> complicated than staging a hunk or a line, I personally prefer the `edit`
> command *a lot*, as it lets me even split unrelated changes in the same
> line into two commits.

I was hoping for something simpler than editing patches just to stage a 
subset of lines that do not need to be edited.

>> and it could be awkward to get it to stage modified lines correctly
>> (While I was writing the feature I tried git gui, I think it is supposed
>> to be able to stage modified lines correctly but I never persuaded it to
>> do it for me. I also tried gitg, tig and hg commit -i but I couldn't get
>> them to do modified lines either)
> 
> Git GUI works very reliably for me, but then, I have Git for Windows'
> patched Git GUI at my finger tips (oh how I wish we had a Git GUI
> maintainer again).
> 
> It should not be awkward to stage a single modified line at all.
> Essentially, you take the hunk, strip out all `-` and `+` lines except the
> one you want to stage, then stage that with `git apply --cached
> --recount`, and then you simply re-generate that hunk.

But that involves editing the hunk or have I misunderstood? The aim of 
my series was that you'd select the '-' & '+' lines for the modification 
and it would stage them properly as a modification so given

1 -a
2 -b
3 +c

selecting 1,3 would stage

-a
+c
  b

not

-a
  b
+c

(see https://public-inbox.org/git/878ta8vyqe.fsf@evledraar.gmail.com/ 
for the background)

>> I'll try and re-roll in the New Year, when does the outreachy project
>> for converting add -i start? - it would be good to try and get this
>> pinned down before then.
> 
> Too late. Slavica started on December 4th, and you can even read about it
> on their blog: https://slavicadj.github.io/blog/

Thanks for the link and hello Slavica! - I look forward to reading your 
patches when you post them here.

Best Wishes

Phillip

Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Alban Gruin]

Hi Junio,

Le 09/12/2018 à 09:42, Junio C Hamano a écrit :> -%<-
> * ag/sequencer-reduce-rewriting-todo (2018-11-12) 16 commits
>  . rebase--interactive: move transform_todo_file() to
rebase--interactive.c
>  . sequencer: fix a call to error() in transform_todo_file()
>  . sequencer: use edit_todo_list() in complete_action()
>  . rebase-interactive: rewrite edit_todo_list() to handle the initial edit
>  . rebase-interactive: append_todo_help() changes
>  . rebase-interactive: use todo_list_write_to_file() in edit_todo_list()
>  . sequencer: refactor skip_unnecessary_picks() to work on a todo_list
>  . sequencer: change complete_action() to use the refactored functions
>  . sequencer: make sequencer_make_script() write its script to a strbuf
>  . sequencer: refactor rearrange_squash() to work on a todo_list
>  . sequencer: refactor sequencer_add_exec_commands() to work on a
todo_list
>  . sequencer: refactor check_todo_list() to work on a todo_list
>  . sequencer: introduce todo_list_write_to_file()
>  . sequencer: refactor transform_todos() to work on a todo_list
>  . sequencer: make the todo_list structure public
>  . sequencer: changes in parse_insn_buffer()
>
>  The scripted version of "git rebase -i" wrote and rewrote the todo
>  list many times during a single step of its operation, and the
>  recent C-rewrite made a faithful conversion of the logic to C.  The
>  implementation has been updated to carry necessary information
>  around in-core to avoid rewriting the same file over and over
>  unnecessarily.
>
>  With too many topics in-flight that touch sequencer and rebaser,
>  this need to wait giving precedence to other topics that fix bugs.
>

If I’m not mistaken, there is currently 3 others series touching rebase,
rebase-interactive and/or the sequencer: en/rebase-merge-on-sequencer,
nd/the-index, and the new js/rebase-i-redo-exec.  Among these, I believe
only nd/the-index actually touches the same places as
ag/sequencer-reduce-rewriting-todo, and is not a behaviour change.

Is this safe to reroll this in the next few days?

--
Alban

Re: pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Johannes Schindelin]

Hi Phillip,


On Tue, 11 Dec 2018, Phillip Wood wrote:

> On 11/12/2018 09:56, Johannes Schindelin wrote:
> 
> > On Mon, 10 Dec 2018, Phillip Wood wrote:
> > 
> > > On 09/12/2018 20:31, Johannes Schindelin wrote:
> > >
> > > > I could imagine, however, that it would make sense for `git add
> > > > -p` to imitate that feature more closely: by allowing to stage a
> > > > single line and then presenting the current hunk (re-computed)
> > > > again.
> > >
> > > that sounds like it would be quite tedious to stage more than a
> > > couple of lines,
> > 
> > It would be. But then, if you want to do anything slightly more
> > complicated than staging a hunk or a line, I personally prefer the
> > `edit` command *a lot*, as it lets me even split unrelated changes in
> > the same line into two commits.
> 
> I was hoping for something simpler than editing patches just to stage a
> subset of lines that do not need to be edited.

Personally, I found that Git GUI's "Stage selected lines" worked well,
even if I could only mark consecutive lines. That might be a valuable
simplification in your case, too, to allow either individual lines to be
staged, or alternatively a simple start-end range.

The trick, of course, is to present the updated hunk after staging the
line(s)... That's what makes it so fun to use in Git GUI.

> > > and it could be awkward to get it to stage modified lines correctly
> > > (While I was writing the feature I tried git gui, I think it is
> > > supposed to be able to stage modified lines correctly but I never
> > > persuaded it to do it for me. I also tried gitg, tig and hg commit
> > > -i but I couldn't get them to do modified lines either)
> > 
> > Git GUI works very reliably for me, but then, I have Git for Windows'
> > patched Git GUI at my finger tips (oh how I wish we had a Git GUI
> > maintainer again).
> > 
> > It should not be awkward to stage a single modified line at all.
> > Essentially, you take the hunk, strip out all `-` and `+` lines except
> > the one you want to stage, then stage that with `git apply --cached
> > --recount`, and then you simply re-generate that hunk.
> 
> But that involves editing the hunk or have I misunderstood? The aim of
> my series was that you'd select the '-' & '+' lines for the modification
> and it would stage them properly as a modification so given
> 
> 1 -a
> 2 -b
> 3 +c
> 
> selecting 1,3 would stage
> 
> -a
> +c
>  b
> 
> not
> 
> -a
>  b
> +c
> 
> (see https://public-inbox.org/git/878ta8vyqe.fsf@evledraar.gmail.com/
> for the background)

Why not staging them as line 1 first, then seeing an updated hunk and
staging the next one? That's an easier UI to begin with.

Ciao,
Dscho

Re: pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Phillip Wood]

Hi Dscho

On 21/01/2019 20:58, Johannes Schindelin wrote:
> Hi Phillip,
> 
> 
> On Tue, 11 Dec 2018, Phillip Wood wrote:
> 
>> On 11/12/2018 09:56, Johannes Schindelin wrote:
>>
>>> On Mon, 10 Dec 2018, Phillip Wood wrote:
>>>
>>>> On 09/12/2018 20:31, Johannes Schindelin wrote:
>>>>
>>>>> I could imagine, however, that it would make sense for `git add
>>>>> -p` to imitate that feature more closely: by allowing to stage a
>>>>> single line and then presenting the current hunk (re-computed)
>>>>> again.
>>>>
>>>> that sounds like it would be quite tedious to stage more than a
>>>> couple of lines,
>>>
>>> It would be. But then, if you want to do anything slightly more
>>> complicated than staging a hunk or a line, I personally prefer the
>>> `edit` command *a lot*, as it lets me even split unrelated changes in
>>> the same line into two commits.
>>
>> I was hoping for something simpler than editing patches just to stage a
>> subset of lines that do not need to be edited.
> 
> Personally, I found that Git GUI's "Stage selected lines" worked well,
> even if I could only mark consecutive lines. That might be a valuable
> simplification in your case, too, to allow either individual lines to be
> staged, or alternatively a simple start-end range.
> 
> The trick, of course, is to present the updated hunk after staging the
> line(s)... That's what makes it so fun to use in Git GUI.
> 
>>>> and it could be awkward to get it to stage modified lines correctly
>>>> (While I was writing the feature I tried git gui, I think it is
>>>> supposed to be able to stage modified lines correctly but I never
>>>> persuaded it to do it for me. I also tried gitg, tig and hg commit
>>>> -i but I couldn't get them to do modified lines either)
>>>
>>> Git GUI works very reliably for me, but then, I have Git for Windows'
>>> patched Git GUI at my finger tips (oh how I wish we had a Git GUI
>>> maintainer again).
>>>
>>> It should not be awkward to stage a single modified line at all.
>>> Essentially, you take the hunk, strip out all `-` and `+` lines except
>>> the one you want to stage, then stage that with `git apply --cached
>>> --recount`, and then you simply re-generate that hunk.
>>
>> But that involves editing the hunk or have I misunderstood? The aim of
>> my series was that you'd select the '-' & '+' lines for the modification
>> and it would stage them properly as a modification so given
>>
>> 1 -a
>> 2 -b
>> 3 +c
>>
>> selecting 1,3 would stage
>>
>> -a
>> +c
>>   b
>>
>> not
>>
>> -a
>>   b
>> +c
>>
>> (see https://public-inbox.org/git/878ta8vyqe.fsf@evledraar.gmail.com/
>> for the background)
> 
> Why not staging them as line 1 first, then seeing an updated hunk and
> staging the next one? That's an easier UI to begin with.

If you stage line 1 first then the hunk would look like

1 -b
2 +c

If you then select line 2 you end up with

  b
+c

Which is not what you want if you're trying to stage the modified line a 
-> c. git-gui has some magic to get around this [1] but I found it hard 
to use when I tried it out a while ago - I think you have to stage the 
lines in a particular order for it to work.

[1] 
https://repo.or.cz/git-gui.git/commit/c7f7457026dc2f6979842f81cc17098579fec8d8

Best Wishes

Phillip

> 
> Ciao,
> Dscho
>