threads / discuss / 49982

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

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

## tl;dr

20 messages between Dec 9, 2018 and Jan 22, 2019.

replies: 19people: 9as markdown or json

Junio C Hamano· Dec 9, 2018, 08:42 UTC · lore

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'.
Denton Liu· Dec 9, 2018, 09:03 UTC · re: Junio C Hamano · lore

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

On Sun, Dec 09, 2018 at 05:42:27PM +0900, Junio C Hamano wrote:
Show 12 quoted lines
> * 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.

Show 9 quoted lines
> 
> * 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/
Junio C Hamano· Dec 10, 2018, 03:21 UTC · re: Denton Liu · lore

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

Denton Liu <liu.denton@gmail.com> writes:
Show 17 quoted lines
> 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.

Show 10 quoted lines
>> * 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/
Denton Liu· Dec 10, 2018, 03:52 UTC · re: Junio C Hamano · lore

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

On Mon, Dec 10, 2018 at 12:21:05PM +0900, Junio C Hamano wrote:
Show 35 quoted lines
> 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.

Show 28 quoted lines
> 
> 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.

Show 9 quoted lines
> 
> Without that, I remain unconvinced.
> 
> Thanks.
> 
> 
> [Reference]
> 
> *1*  https://public-inbox.org/git/1d1b0fe85ddd89cf8172e730e8886d5b4a9ea7eb.1540627720.git.liu.denton@gmail.com/
Junio C Hamano· Dec 10, 2018, 10:26 UTC · re: Denton Liu · lore

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

Denton Liu <liu.denton@gmail.com> writes:
Show 10 quoted lines
> 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,
Show 6 quoted lines
>> ....  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.
Johannes Schindelin· Dec 9, 2018, 20:31 UTC · re: Junio C Hamano · lore

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

Hi Junio,
On Sun, 9 Dec 2018, Junio C Hamano wrote:
Show 12 quoted lines
> * 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

Phillip Wood· Dec 10, 2018, 10:42 UTC · re: Johannes Schindelin · lore

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

Hi Dscho
On 09/12/2018 20:31, Johannes Schindelin wrote:
Show 18 quoted lines
> 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.

Show 5 quoted lines
> 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
> 
Johannes Schindelin· Dec 11, 2018, 09:56 UTC · re: Phillip Wood · lore

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

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:
Show 20 quoted lines
> 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.

Show 8 quoted lines
> > 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.

Show 5 quoted 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)

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

Phillip Wood· Dec 11, 2018, 14:48 UTC · re: Johannes Schindelin · lore

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

Hi Dscho and Slavica
On 11/12/2018 09:56, Johannes Schindelin wrote:
Show 9 quoted lines
> 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/>
Show 9 quoted lines
>>> (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
Show 13 quoted lines
>>> 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.

Show 14 quoted 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)
> 
> 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)

Show 6 quoted lines
>> 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
Johannes Schindelin· Jan 21, 2019, 20:58 UTC · re: Phillip Wood · lore

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

Hi Phillip,
On Tue, 11 Dec 2018, Phillip Wood wrote:
Show 21 quoted lines
> 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.

Show 37 quoted 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)
> > 
> > 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

Phillip Wood· Jan 22, 2019, 20:27 UTC · re: Johannes Schindelin · lore

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

Hi Dscho
On 21/01/2019 20:58, Johannes Schindelin wrote:
Show 75 quoted lines
> 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
> 
Josh Steadmon· Dec 10, 2018, 18:53 UTC · re: Junio C Hamano · lore

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

On 2018.12.09 17:42, Junio C Hamano wrote:
Show 9 quoted lines
> * 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.

Show 10 quoted lines
> * 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.

Junio C Hamano· Dec 11, 2018, 01:43 UTC · re: Josh Steadmon · lore

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

Josh Steadmon <steadmon@google.com> writes:
Show 14 quoted lines
> 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.

Show 16 quoted lines
>> * 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.

Elijah Newren· Dec 10, 2018, 20:05 UTC · re: Junio C Hamano · lore

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

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

Ævar Arnfjörð Bjarmason· Dec 10, 2018, 21:50 UTC · re: Elijah Newren · lore

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

On Mon, Dec 10 2018, Elijah Newren wrote:
Show 14 quoted lines
> 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.

Junio C Hamano· Dec 11, 2018, 01:49 UTC · re: Ævar Arnfjörð Bjarmason · lore

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

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 8 quoted lines
> 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'.

Junio C Hamano· Dec 11, 2018, 01:48 UTC · re: Elijah Newren · lore

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

Elijah Newren <newren@gmail.com> writes:
Show 10 quoted lines
> 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.

Stefan Beller· Dec 11, 2018, 02:00 UTC · re: Junio C Hamano · lore

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

Show 7 quoted lines
> * 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.
Show 6 quoted lines
> * 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. :-)

Junio C Hamano· Dec 11, 2018, 06:17 UTC · re: Stefan Beller · lore

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

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?
Alban Gruin· Dec 16, 2018, 21:48 UTC · re: Junio C Hamano · lore

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

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
Show 10 quoted lines
>  . 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
Show 16 quoted lines
>  . 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

← back to recent threads