{"thread":{"id":"49982","subject":"What's cooking in git.git (Dec 2018, #01; Sun, 9)","startedAt":"2018-12-09T08:42:38Z","lastAt":"2019-01-22T20:27:10Z","messageCount":20,"participants":["Junio C Hamano","Denton Liu","Johannes Schindelin","Phillip Wood","Josh Steadmon","Elijah Newren","Ævar Arnfjörð Bjarmason","Stefan Beller","Alban Gruin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"364838","messageId":"xmqq8t0z3xcc.fsf@gitster-ct.c.googlers.com","threadId":"49982","inReplyTo":null,"subject":"What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-12-09T08:42:27Z","receivedAt":"2018-12-09T08:42:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed with\n'-' are only in 'pu' (proposed updates) while commits prefixed with\n'+' are in 'next'. The ones marked with '.' do not appear in any of\nthe integration branches, but I am still holding onto them.\n\nGit 2.20 has been tagged. I'd expect that we would slow down to see\nhow stable it is and queue only the brown-paper-bag fixes for a week\nor so, before opening the tree for the next cycle, rewinding the tip\nof 'next', etc.\n\nYou can find the changes described here in the integration branches\nof the repositories listed at\n\n http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* ab/push-example-in-doc (2018-11-14) 1 commit\n (merged to 'next' on 2018-11-18 at 8fd935a19c)\n + push: change needlessly ambiguous example in error\n\n An error message that sugggests how to give correct arguments to\n \"git push\" has been updated.\n\n\n* ab/replace-graft-with-replace-advice (2018-11-29) 1 commit\n (merged to 'next' on 2018-11-30 at c5d658e075)\n + advice: don't pointlessly suggest --convert-graft-file\n\n The advice message to tell the user to migrate an existing graft\n file to the replace system when a graft file was read was shown\n even when \"git replace --convert-graft-file\" command, which is the\n way the message suggests to use, was running, which made little\n sense.\n\n\n* gh/diff-raw-has-no-ellipses (2018-11-26) 1 commit\n (merged to 'next' on 2018-11-29 at 24a7536f15)\n + doc: update diff-format.txt for removed ellipses in --raw\n\n \"git diff --raw\" lost ellipses to adjust the output columns for\n some time now, but the documentation still showed them.\n\n\n* jc/format-patch-range-diff-fix (2018-11-30) 1 commit\n (merged to 'next' on 2018-11-30 at 26290b1ec1)\n + format-patch: do not let its diff-options affect --range-diff\n\n \"git format-patch --range-diff\" by mistake passed the diff options\n used to generate the primary output of the command to the\n range-diff machinery, which caused the range-diff in the cover\n letter to include fairly useless \"--stat\" output. This has been\n corrected by forcing a non-customizable default formatting options\n on the range-diff machinery when driven by format-patch.\n\n\n* js/rebase-reflog-action-fix (2018-11-30) 1 commit\n (merged to 'next' on 2018-11-30 at 93fd2fb920)\n + rebase: fix GIT_REFLOG_ACTION regression\n\n \"git rebase\" reimplemented recently in C accidentally changed the\n way reflog entries are recorded (earlier \"rebase -i\" identified the\n entries it leaves with \"rebase -i\", but the new version always\n marks them with \"rebase\"). This has been corrected.\n\n\n* js/rebase-stat-unrelated-fix (2018-11-30) 1 commit\n (merged to 'next' on 2018-11-30 at a9faaff8c1)\n + rebase --stat: fix when rebasing to an unrelated history\n\n \"git rebase --stat\" to transplant a piece of history onto a totally\n unrelated history were not working before and silently showed wrong\n result. With the recent reimplementation in C, it started to instead\n die with an error message, as the original logic was not prepared\n to cope with this case. This has now been fixed.\n\n\n* ma/reset-doc-rendering-fix (2018-11-29) 2 commits\n (merged to 'next' on 2018-11-30 at be718c19e2)\n + git-reset.txt: render literal examples as monospace\n + git-reset.txt: render tables correctly under Asciidoctor\n\n Doc updates.\n\n\n* rt/rebase-in-c-message-fix (2018-12-01) 1 commit\n (merged to 'next' on 2018-12-01 at 4428c15a66)\n + builtin/rebase.c: remove superfluous space in messages\n\n\n* sg/daemon-test-signal-fix (2018-11-27) 1 commit\n (merged to 'next' on 2018-11-30 at b3f7fdf727)\n + t/lib-git-daemon: fix signal checking\n\n Test fix.\n\n\n* sg/test-BUG (2018-11-20) 1 commit\n (merged to 'next' on 2018-11-21 at bb81013952)\n + tests: send \"bug in the test script\" errors to the script's stderr\n\n test framework has been updated to make a bug in the test script\n (as opposed to bugs in Git that are discovered by running the\n tests) stand out more prominently.\n\n\n* sg/test-cmp-rev (2018-11-20) 1 commit\n (merged to 'next' on 2018-11-21 at 5d65cb2a76)\n + test-lib-functions: make 'test_cmp_rev' more informative on failure\n\n Test framework update.\n\n\n* ss/msvc-strcasecmp (2018-11-20) 1 commit\n (merged to 'next' on 2018-11-21 at 9e45649e6e)\n + msvc: directly use MS version (_stricmp) of strcasecmp\n\n MSVC update.\n\n--------------------------------------------------\n[New Topics]\n\n* cb/openbsd-allows-reading-directory (2018-12-03) 1 commit\n - config.mak.uname: OpenBSD uses BSD semantics with fread for directories\n\n BSD port update.\n\n Will merge to 'next'.\n\n\n* cb/t5004-empty-tar-archive-fix (2018-12-03) 1 commit\n - t5004: avoid using tar for empty packages\n\n BSD port update.\n\n Will merge to 'next'.\n\n\n* cb/test-lint-cp-a (2018-12-03) 1 commit\n - tests: add lint for non portable cp -a\n\n BSD port update.\n\n Will merge to 'next'.\n\n\n* hb/t0061-dot-in-path-fix (2018-12-03) 1 commit\n - t0061: do not fail test if '.' is part of $PATH\n\n Test update.\n\n Will merge to 'next'.\n\n\n* hn/highlight-sideband-keywords (2018-12-04) 1 commit\n - sideband: color lines with keyword only\n\n Lines that begin with a certain keyword that come over the wire, as\n well as lines that consist only of one of these keywords, ought to\n be painted in color for easier eyeballing, but the latter was\n broken ever since the feature was introduced in 2.19, which has\n been corrected.\n\n Will merge to 'next'.\n\n\n* js/commit-graph-chunk-table-fix (2018-12-09) 4 commits\n - SQUASH???\n - Makefile: correct example fuzz build\n - commit-graph: fix buffer read-overflow\n - commit-graph, fuzz: add fuzzer for commit-graph\n\n The codepath to read from the commit-graph file attempted to read\n past the end of it when the file's table-of-contents was corrupt.\n\n\n* jt/get-reference-with-commit-graph (2018-12-06) 1 commit\n - revision: use commit graph in get_reference()\n (this branch uses sb/more-repo-in-api.)\n\n Micro-optimize the code that prepares commit objects to be walked\n by \"git rev-list\" when the commit-graph is available.\n\n Will merge to 'next'.\n\n\n* md/exclude-promisor-objects-fix-cleanup (2018-12-06) 1 commit\n - revision.c: put promisor option in specialized struct\n\n Code clean-up.\n\n Will merge to 'next'.\n\n\n* bw/mailmap (2018-12-09) 1 commit\n - mailmap: update Brandon Williams's email address\n\n Will merge to 'next'.\n\n\n* do/gitweb-strict-export-conf-doc (2018-12-09) 1 commit\n - docs: fix $strict_export text in gitweb.conf.txt\n\n Doc update.\n\n Will merge to 'next'.\n\n\n* en/directory-renames-nothanks-doc-update (2018-12-09) 1 commit\n - git-rebase.txt: update note about directory rename detection and am\n\n Doc update.\n\n Will merge to 'next'.\n\n\n* fd/gitweb-snapshot-conf-doc-fix (2018-12-09) 1 commit\n - docs/gitweb.conf: config variable typo\n\n Doc update.\n\n Will merge to 'next'.\n\n\n* km/rebase-doc-typofix (2018-12-09) 1 commit\n - rebase docs: drop stray word in merge command description\n\n Doc update.\n\n Will merge to 'next'.\n\n\n* nd/indentation-fix (2018-12-09) 1 commit\n - Indent code with TABs\n\n Code cleanup.\n\n Will merge to 'next'.\n\n\n* tb/use-common-win32-pathfuncs-on-cygwin (2018-12-09) 1 commit\n - git clone C:\\cygwin\\home\\USER\\repo' is working (again)\n\n Cygwin update.\n\n Will merge to 'next'.\n\n--------------------------------------------------\n[Stalled]\n\n* lt/date-human (2018-07-09) 1 commit\n - Add 'human' date format\n\n A new date format \"--date=human\" that morphs its output depending\n on how far the time is from the current time has been introduced.\n \"--date=auto\" can be used to use this new format when the output is\n goint to the pager or to the terminal and otherwise the default\n format.\n\n--------------------------------------------------\n[Cooking]\n\n* mk/http-backend-kill-children-before-exit (2018-11-26) 1 commit\n (merged to 'next' on 2018-11-29 at bf2d45062f)\n + http-backend: enable cleaning up forked upload/receive-pack on exit\n\n The http-backend CGI process did not correctly clean up the child\n processes it spawns to run upload-pack etc. when it dies itself,\n which has been corrected.\n\n Will cook in 'next'.\n\n\n* tb/log-G-binary (2018-11-29) 1 commit\n - log -G: ignore binary files\n\n \"git log -G\" looked for a hunk in the \"git log -p\" patch\n output that contained a string that matches the given pattern.\n Optimize this code to ignore binary files, which by default will\n not show any hunk that would match any pattern (unless textconv or\n the --text option is in effect, that is).\n\n Expecting an update to the tests.\n\n\n* dl/merge-cleanup-scissors-fix (2018-11-21) 2 commits\n (merged to 'next' on 2018-11-21 at 217be06acb)\n + merge: add scissors line on merge conflict\n + t7600: clean up 'merge --squash c3 with c7' test\n\n The list of conflicted paths shown in the editor while concluding a\n conflicted merge was shown above the scissors line when the\n clean-up mode is set to \"scissors\", even though it was commented\n out just like the list of updated paths and other information to\n help the user explain the merge better.\n\n Will cook in 'next'.\n\n\n* aw/pretty-trailers (2018-12-09) 7 commits\n - pretty: add support for separator option in %(trailers)\n - strbuf: separate callback for strbuf_expand:ing literals\n - pretty: add support for \"valueonly\" option in %(trailers)\n - pretty: allow showing specific trailers\n - pretty: single return path in %(trailers) handling\n - pretty: allow %(trailers) options with explicit value\n - doc: group pretty-format.txt placeholders descriptions\n\n The %(trailers) formatter in \"git log --format=...\" now allows to\n optionally pick trailers selectively by keyword, show only values,\n etc.\n\n How's the doneness of this one?\n\n\n* nd/attr-pathspec-in-tree-walk (2018-11-19) 5 commits\n - tree-walk: support :(attr) matching\n - dir.c: move, rename and export match_attrs()\n - pathspec.h: clean up \"extern\" in function declarations\n - tree-walk.c: make tree_entry_interesting() take an index\n - tree.c: make read_tree*() take 'struct repository *'\n\n The traversal over tree objects has learned to honor\n \":(attr:label)\" pathspec match, which has been implemented only for\n enumerating paths on the filesystem.\n\n Will merge to 'next'.\n\n\n* ab/commit-graph-progress-fix (2018-11-20) 1 commit\n - commit-graph: split up close_reachable() progress output\n\n Will merge to 'next'.\n\n\n* jn/unknown-index-extensions (2018-11-21) 2 commits\n - index: offer advice for unknown index extensions\n - index: do not warn about unrecognized extensions\n\n A bit too alarming warning given when unknown index extensions\n exist is getting revamped.\n\n Expecting a reroll.\n\n\n* en/fast-export-import (2018-11-17) 11 commits\n (merged to 'next' on 2018-11-18 at 87bbbffc95)\n + fast-export: add a --show-original-ids option to show original names\n + fast-import: remove unmaintained duplicate documentation\n + fast-export: add --reference-excluded-parents option\n + fast-export: ensure we export requested refs\n + fast-export: when using paths, avoid corrupt stream with non-existent mark\n + fast-export: move commit rewriting logic into a function for reuse\n + fast-export: avoid dying when filtering by paths and old tags exist\n + fast-export: use value from correct enum\n + git-fast-export.txt: clarify misleading documentation about rev-list args\n + git-fast-import.txt: fix documentation for --quiet option\n + fast-export: convert sha1 to oid\n\n Small fixes and features for fast-export and fast-import, mostly on\n the fast-export side.\n\n Will cook in 'next'.\n\n\n* nd/checkout-dwim-fix (2018-11-14) 1 commit\n (merged to 'next' on 2018-11-18 at 3d714e7719)\n + checkout: disambiguate dwim tracking branches and local files\n\n \"git checkout frotz\" (without any double-dash) avoids ambiguity by\n making sure 'frotz' cannot be interpreted as a revision and as a\n path at the same time. This safety has been updated to check also\n a unique remote-tracking branch 'frotz' in a remote, when dwimming\n to create a local branch 'frotz' out of a remote-tracking branch\n 'frotz' from a remote.\n\n Will cook in 'next'.\n\n\n* nd/checkout-noisy (2018-11-20) 2 commits\n - t0027: squelch checkout path run outside test_expect_* block\n - checkout: print something when checking out paths\n\n \"git checkout [] path...\" learned to report the number of\n paths that have been checked out of the index or the tree-ish,\n which gives it the same degree of noisy-ness as the case in which\n the command checks out a branch.\n\n Will merge to 'next'.\n\n\n* sg/clone-initial-fetch-configuration (2018-11-16) 3 commits\n (merged to 'next' on 2018-11-18 at cae0f3985b)\n + Documentation/clone: document ignored configuration variables\n + clone: respect additional configured fetch refspecs during initial fetch\n + clone: use a more appropriate variable name for the default refspec\n\n Refspecs configured with \"git -c var=val clone\" did not propagate\n to the resulting repository, which has been corrected.\n\n Will cook in 'next'.\n\n\n* en/rebase-merge-on-sequencer (2018-11-08) 2 commits\n - rebase: implement --merge via git-rebase--interactive\n - git-rebase, sequencer: extend --quiet option for the interactive machinery\n\n \"git rebase --merge\" as been reimplemented by reusing the internal\n machinery used for \"git rebase -i\".\n\n Expecting a reroll.\n cf. \n\n\n* fc/http-version (2018-11-09) 1 commit\n (merged to 'next' on 2018-11-18 at 42f5155095)\n + http: add support selecting http version\n\n The \"http.version\" configuration variable can be used with recent\n enough cURL library to force the version of HTTP used to talk when\n fetching and pushing.\n\n Will cook in 'next'.\n\n\n* dl/remote-save-to-push (2018-11-13) 1 commit\n - remote: add --save-to-push option to git remote set-url\n\n \"git remote set-url\" learned a new option that moves existing value\n of the URL field to pushURL field of the remote before replacing\n the URL field with a new value.\n\n I am personally not yet quite convinced if this is worth pursuing.\n\n\n* jk/loose-object-cache (2018-11-24) 10 commits\n (merged to 'next' on 2018-11-24 at 5f4f22707d)\n + odb_load_loose_cache: fix strbuf leak\n (merged to 'next' on 2018-11-18 at 276691a21b)\n + fetch-pack: drop custom loose object cache\n + sha1-file: use loose object cache for quick existence check\n + object-store: provide helpers for loose_objects_cache\n + sha1-file: use an object_directory for the main object dir\n + handle alternates paths the same as the main object dir\n + sha1_file_name(): overwrite buffer instead of appending\n + rename \"alternate_object_database\" to \"object_directory\"\n + submodule--helper: prefer strip_suffix() to ends_with()\n + fsck: do not reuse child_process structs\n\n Code clean-up with optimization for the codepath that checks\n (non-)existence of loose objects.\n\n Will cook in 'next'.\n\n\n* js/protocol-advertise-multi (2018-11-17) 1 commit\n - protocol: advertise multiple supported versions\n\n The transport layer has been updated so that the protocol version\n used can be negotiated between the parties, by the initiator\n listing the protocol versions it is willing to talk, and the other\n side choosing from one of them.\n\n How's the doneness of this one?\n\n\n* js/smart-http-detect-remote-error (2018-11-17) 3 commits\n (merged to 'next' on 2018-11-18 at 5c6edfcb85)\n + remote-curl: die on server-side errors\n + remote-curl: tighten \"version 2\" check for smart-http\n + remote-curl: refactor smart-http discovery\n\n Some errors from the other side coming over smart HTTP transport\n were not noticed, which has been corrected.\n\n Will cook in 'next'.\n\n\n* nb/branch-show-other-worktrees-head (2018-11-12) 2 commits\n - branch: mark and colorize a branch differently if it is checked out in a linked worktree\n - ref-filter: add worktree atom\n\n \"git branch --list\" learned to show branches that are checked out\n in other worktrees connected to the same repository prefixed with\n '+', similar to the way the currently checked out branch is shown\n with '*' in front.\n\n Expecting a reroll.\n\n\n* nd/the-index (2018-11-12) 22 commits\n (merged to 'next' on 2018-11-18 at 73d1d8594e)\n + rebase-interactive.c: remove the_repository references\n + rerere.c: remove the_repository references\n + pack-*.c: remove the_repository references\n + pack-check.c: remove the_repository references\n + notes-cache.c: remove the_repository references\n + line-log.c: remove the_repository reference\n + diff-lib.c: remove the_repository references\n + delta-islands.c: remove the_repository references\n + cache-tree.c: remove the_repository references\n + bundle.c: remove the_repository references\n + branch.c: remove the_repository reference\n + bisect.c: remove the_repository reference\n + blame.c: remove implicit dependency the_repository\n + sequencer.c: remove implicit dependency on the_repository\n + sequencer.c: remove implicit dependency on the_index\n + transport.c: remove implicit dependency on the_index\n + notes-merge.c: remove implicit dependency the_repository\n + notes-merge.c: remove implicit dependency on the_index\n + list-objects.c: reduce the_repository references\n + list-objects-filter.c: remove implicit dependency on the_index\n + wt-status.c: remove implicit dependency the_repository\n + wt-status.c: remove implicit dependency on the_index\n\n More codepaths become aware of working with in-core repository\n instance other than the default \"the_repository\".\n\n Will cook in 'next'.\n\n\n* ot/ref-filter-object-info (2018-11-24) 6 commits\n (merged to 'next' on 2018-11-24 at f8505762e3)\n + ref-filter: replace unportable `%lld` format with %PRIdMAX\n (merged to 'next' on 2018-11-18 at ad4c086678)\n + ref-filter: add docs for new options\n + ref-filter: add tests for deltabase\n + ref-filter: add deltabase option\n + ref-filter: add tests for objectsize:disk\n + ref-filter: add objectsize:disk option\n\n The \"--format=\" option of for-each-ref, branch and tag\n learned to show a few more traits of objects that can be learned by\n the object_info API.\n\n Will cook in 'next'.\n\n\n* sb/diff-color-moved-config-option-fixup (2018-11-14) 1 commit\n - diff: align move detection error handling with other options\n\n Minor inconsistency fix.\n\n Will merge to 'next'.\n\n\n* ab/push-dwim-dst (2018-11-14) 7 commits\n (merged to 'next' on 2018-11-18 at 36567023be)\n + push doc: document the DWYM behavior pushing to unqualified \n + push: test that doesn't DWYM if is unqualified\n + push: add an advice on unqualified push\n + push: move unqualified refname error into a function\n + push: improve the error shown on unqualified push\n + i18n: remote.c: mark error(...) messages for translation\n + remote.c: add braces in anticipation of a follow-up change\n\n \"git push $there $src:$dst\" rejects when $dst is not a fully\n qualified refname and not clear what the end user meant. The\n codepath has been taught to give a clearer error message, and also\n guess where the push should go by taking the type of the pushed\n object into account (e.g. a tag object would want to go under\n refs/tags/).\n\n Will cook in 'next'.\n\n\n* md/list-lazy-objects-fix (2018-12-06) 1 commit\n - list-objects.c: don't segfault for missing cmdline objects\n\n \"git rev-list --exclude-promissor-objects\" had to take an object\n that does not exist locally (and is lazily available) from the\n command line without barfing, but the code dereferenced NULL.\n\n Will merge to 'next'.\n\n\n* nd/i18n (2018-11-12) 16 commits\n (merged to 'next' on 2018-11-18 at 5215bd2f7d)\n + fsck: mark strings for translation\n + fsck: reduce word legos to help i18n\n + parse-options.c: mark more strings for translation\n + parse-options.c: turn some die() to BUG()\n + parse-options: replace opterror() with optname()\n + repack: mark more strings for translation\n + remote.c: mark messages for translation\n + remote.c: turn some error() or die() to BUG()\n + reflog: mark strings for translation\n + read-cache.c: add missing colon separators\n + read-cache.c: mark more strings for translation\n + read-cache.c: turn die(\"internal error\") to BUG()\n + attr.c: mark more string for translation\n + archive.c: mark more strings for translation\n + alias.c: mark split_cmdline_strerror() strings for translation\n + git.c: mark more strings for translation\n\n More _(\"i18n\") markings.\n\n Will cook in 'next'.\n\n\n* sb/more-repo-in-api (2018-11-14) 23 commits\n (merged to 'next' on 2018-11-19 at e5d2a129da)\n + t/helper/test-repository: celebrate independence from the_repository\n + path.h: make REPO_GIT_PATH_FUNC repository agnostic\n + commit: prepare free_commit_buffer and release_commit_memory for any repo\n + commit-graph: convert remaining functions to handle any repo\n + submodule: don't add submodule as odb for push\n + submodule: use submodule repos for object lookup\n + pretty: prepare format_commit_message to handle arbitrary repositories\n + commit: prepare logmsg_reencode to handle arbitrary repositories\n + commit: prepare repo_unuse_commit_buffer to handle any repo\n + commit: prepare get_commit_buffer to handle any repo\n + commit-reach: prepare in_merge_bases[_many] to handle any repo\n + commit-reach: prepare get_merge_bases to handle any repo\n + commit-reach.c: allow get_merge_bases_many_0 to handle any repo\n + commit-reach.c: allow remove_redundant to handle any repo\n + commit-reach.c: allow merge_bases_many to handle any repo\n + commit-reach.c: allow paint_down_to_common to handle any repo\n + commit: allow parse_commit* to handle any repo\n + object: parse_object to honor its repository argument\n + object-store: prepare has_{sha1, object}_file to handle any repo\n + object-store: prepare read_object_file to deal with any repo\n + object-store: allow read_object_file_extended to read from any repo\n + packfile: allow has_packed_and_bad to handle arbitrary repositories\n + sha1_file: allow read_object to read objects in arbitrary repositories\n (this branch is used by jt/get-reference-with-commit-graph.)\n\n The in-core repository instances are passed through more codepaths.\n\n Will cook in 'next'.\n cf. <20181115221254.45373-1-jonathantanmy@google.com>\n\n\n* en/merge-path-collision (2018-12-01) 11 commits\n (merged to 'next' on 2018-12-01 at 24492e61f1)\n + t6036: avoid non-portable \"cp -a\"\n (merged to 'next' on 2018-11-18 at 3ec9286e0b)\n + merge-recursive: combine error handling\n + t6036, t6043: increase code coverage for file collision handling\n + merge-recursive: improve rename/rename(1to2)/add[/add] handling\n + merge-recursive: use handle_file_collision for add/add conflicts\n + merge-recursive: improve handling for rename/rename(2to1) conflicts\n + merge-recursive: fix rename/add conflict handling\n + merge-recursive: new function for better colliding conflict resolutions\n + merge-recursive: increase marker length with depth of recursion\n + t6036, t6042: testcases for rename collision of already conflicting files\n + t6042: add tests for consistency in file collision conflict handling\n\n Updates for corner cases in merge-recursive.\n\n Will cook in 'next'.\n\n\n* sd/stash-wo-user-name (2018-11-19) 1 commit\n (merged to 'next' on 2018-11-19 at 0838b091ea)\n + stash: tolerate missing user identity\n\n A properly configured username/email is required under\n user.useConfigOnly in order to create commits; now \"git stash\"\n (even though it creates commit objects to represent stash entries)\n command is excempt from the requirement.\n\n Will cook in 'next'.\n\n\n* bc/sha-256 (2018-11-14) 12 commits\n - hash: add an SHA-256 implementation using OpenSSL\n - sha256: add an SHA-256 implementation using libgcrypt\n - Add a base implementation of SHA-256 support\n - commit-graph: convert to using the_hash_algo\n - t/helper: add a test helper to compute hash speed\n - sha1-file: add a constant for hash block size\n - t: make the sha1 test-tool helper generic\n - t: add basic tests for our SHA-1 implementation\n - cache: make hashcmp and hasheq work with larger hashes\n - hex: introduce functions to print arbitrary hashes\n - sha1-file: provide functions to look up hash algorithms\n - sha1-file: rename algorithm to \"sha1\"\n\n Add sha-256 hash and plug it through the code to allow building Git\n with the \"NewHash\".\n\n\n* js/vsts-ci (2018-10-16) 13 commits\n . travis: fix skipping tagged releases\n . README: add a build badge (status of the Azure Pipelines build)\n . tests: record more stderr with --write-junit-xml in case of failure\n . tests: include detailed trace logs with --write-junit-xml upon failure\n . git-p4: use `test_atexit` to kill the daemon\n . git-daemon: use `test_atexit` in the tests\n . tests: introduce `test_atexit`\n . ci: add a build definition for Azure DevOps\n . ci/lib.sh: add support for Azure Pipelines\n . tests: optionally write results as JUnit-style .xml\n . test-date: add a subcommand to measure times in shell scripts\n . ci/lib.sh: encapsulate Travis-specific things\n . ci: rename the library of common functions\n\n Prepare to run test suite on Azure DevOps.\n\n Ejected out of 'pu', as doing so seems to help other topics get\n tested at TravisCI.\n\n https://travis-ci.org/git/git/builds/452713184 is a sample of a\n build whose tests on 4 hang (with this series in). Ejecting it\n gave us https://travis-ci.org/git/git/builds/452778963 which still\n shows breakages from other topics not yet in 'next', but at least\n the tests do not stall.\n\n\n* du/branch-show-current (2018-10-26) 1 commit\n - branch: introduce --show-current display option\n\n \"git branch\" learned a new subcommand \"--show-current\".\n\n I am personally not yet quite convinced if this is worth pursuing.\n\n\n* mk/use-size-t-in-zlib (2018-10-15) 1 commit\n - zlib.c: use size_t for size\n\n The wrapper to call into zlib followed our long tradition to use\n \"unsigned long\" for sizes of regions in memory, which have been\n updated to use \"size_t\".\n\n\n* ag/sequencer-reduce-rewriting-todo (2018-11-12) 16 commits\n . rebase--interactive: move transform_todo_file() to rebase--interactive.c\n . sequencer: fix a call to error() in transform_todo_file()\n . sequencer: use edit_todo_list() in complete_action()\n . rebase-interactive: rewrite edit_todo_list() to handle the initial edit\n . rebase-interactive: append_todo_help() changes\n . rebase-interactive: use todo_list_write_to_file() in edit_todo_list()\n . sequencer: refactor skip_unnecessary_picks() to work on a todo_list\n . sequencer: change complete_action() to use the refactored functions\n . sequencer: make sequencer_make_script() write its script to a strbuf\n . sequencer: refactor rearrange_squash() to work on a todo_list\n . sequencer: refactor sequencer_add_exec_commands() to work on a todo_list\n . sequencer: refactor check_todo_list() to work on a todo_list\n . sequencer: introduce todo_list_write_to_file()\n . sequencer: refactor transform_todos() to work on a todo_list\n . sequencer: make the todo_list structure public\n . sequencer: changes in parse_insn_buffer()\n\n The scripted version of \"git rebase -i\" wrote and rewrote the todo\n list many times during a single step of its operation, and the\n recent C-rewrite made a faithful conversion of the logic to C. The\n implementation has been updated to carry necessary information\n around in-core to avoid rewriting the same file over and over\n unnecessarily.\n\n With too many topics in-flight that touch sequencer and rebaser,\n this need to wait giving precedence to other topics that fix bugs.\n\n\n* sb/submodule-recursive-fetch-gets-the-tip (2018-12-09) 9 commits\n - fetch: ensure submodule objects fetched\n - submodule.c: fetch in submodules git directory instead of in worktree\n - submodule: migrate get_next_submodule to use repository structs\n - repository: repo_submodule_init to take a submodule struct\n - submodule: store OIDs in changed_submodule_names\n - submodule.c: tighten scope of changed_submodule_names struct\n - submodule.c: sort changed_submodule_names before searching it\n - submodule.c: fix indentation\n - sha1-array: provide oid_array_filter\n\n \"git fetch --recurse-submodules\" may not fetch the necessary commit\n that is bound to the superproject, which is getting corrected.\n\n Ready?\n\n\n* js/add-i-coalesce-after-editing-hunk (2018-08-28) 1 commit\n - add -p: coalesce hunks before testing applicability\n\n Applicability check after a patch is edited in a \"git add -i/p\"\n session has been improved.\n\n Will hold.\n cf. \n\n\n* ps/stash-in-c (2018-11-26) 22 commits\n . stash: replace all `write-tree` child processes with API calls\n . stash: optimize `get_untracked_files()` and `check_changes()`\n . stash: convert `stash--helper.c` into `stash.c`\n . stash: convert save to builtin\n . stash: make push -q quiet\n . stash: convert push to builtin\n . stash: convert create to builtin\n . stash: convert store to builtin\n . stash: convert show to builtin\n . stash: convert list to builtin\n . stash: convert pop to builtin\n . stash: convert branch to builtin\n . stash: convert drop and clear to builtin\n . stash: convert apply to builtin\n . stash: mention options in `show` synopsis\n . stash: add tests for `git stash show` config\n . stash: rename test cases to be more descriptive\n . t3903: modernize style\n . stash: improve option parsing test coverage\n . strbuf.c: add `strbuf_insertf()` and `strbuf_vinsertf()`\n . strbuf.c: add `strbuf_join_argv()`\n . sha1-name.c: add `get_oidf()` which acts like `get_oid()`\n\n \"git stash\" rewritten in C.\n\n Expecting a reroll, probably on top of the sd/stash-wo-user-name\n topic after it stabilizes, with an escape hatch like the one in\n \"rebase in C\".\n\n\n* pw/add-p-select (2018-07-26) 4 commits\n - add -p: optimize line selection for short hunks\n - add -p: allow line selection to be inverted\n - add -p: select modified lines correctly\n - add -p: select individual hunk lines\n\n \"git add -p\" interactive interface learned to let users choose\n individual added/removed lines to be used in the operation, instead\n of accepting or rejecting a whole hunk.\n\n Will discard.\n No further feedbacks on the topic for quite some time.\n\n cf. \n I found the feature to be hard to explain, and may result in more\n end-user complaints, but let's see.\n\n--------------------------------------------------\n[Discarded]\n\n* ab/reject-alias-loop (2018-10-19) 1 commit\n (merged to 'next' on 2018-10-26 at bc213f1bef)\n + alias: detect loops in mixed execution mode\n\n Two (or more) aliases that mutually refer to each other can form an\n infinite loop; we now attempt to notice and stop.\n\n Discarded.\n Reverted out of 'next'.\n cf. <87sh0slvxm.fsf@evledraar.gmail.com>\n\n\n* gl/bundle-unlock-before-aborting (2018-11-14) 1 commit\n . bundle: rollback lock file while refusing to create an empty bundle\n\n Superseded by jk/close-duped-fd-before-unlock-for-bundle\n\n\n* js/remote-archive-v2 (2018-09-28) 4 commits\n (merged to 'next' on 2018-10-12 at 5f34377f60)\n + archive: allow archive over HTTP(S) with proto v2\n + archive: implement protocol v2 archive command\n + archive: use packet_reader for communications\n + archive: follow test standards around assertions\n\n The original implementation of \"git archive --remote\" more or less\n bypassed the transport layer and did not work over http(s). The\n version 2 of the protocol is defined to allow going over http(s) as\n well as Git native transport.\n\n Retracted; reverted out of next.\n cf. <20181114195142.GI126896@google.com>\n\n\n* ab/format-patch-rangediff-not-stat (2018-11-24) 1 commit\n (merged to 'next' on 2018-11-26 at d9c84916b3)\n + format-patch: don't include --stat with --range-diff output\n\n The \"--rangediff\" option recently added to \"format-patch\"\n interspersed a bogus and useless \"--stat\" information by mistake,\n which is being corrected.\n\n Reverted out of 'next'.\n\n\n* jc/postpone-rebase-in-c (2018-11-26) 1 commit\n (merged to 'next' on 2018-11-26 at c6ae45110f)\n + rebase: mark the C reimplementation as an experimental opt-in feature\n\n People seem to be still finding latent bugs in the \"rebase in C\"\n reimplementation. For the upcoming release, use the scripted\n version by default and adjust the documentation accordingly.\n\n Reverted out of 'next'.\n"},{"id":"364840","messageId":"20181209090300.GA32640@archbookpro.localdomain","threadId":"49982","inReplyTo":"xmqq8t0z3xcc.fsf@gitster-ct.c.googlers.com","subject":"Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2018-12-09T09:03:00Z","receivedAt":"2018-12-09T09:03:05Z","isPatch":false,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"On Sun, Dec 09, 2018 at 05:42:27PM +0900, Junio C Hamano wrote:\n> * dl/merge-cleanup-scissors-fix (2018-11-21) 2 commits\n> (merged to 'next' on 2018-11-21 at 217be06acb)\n> + merge: add scissors line on merge conflict\n> + t7600: clean up 'merge --squash c3 with c7' test\n> \n> The list of conflicted paths shown in the editor while concluding a\n> conflicted merge was shown above the scissors line when the\n> clean-up mode is set to \"scissors\", even though it was commented\n> out just like the list of updated paths and other information to\n> help the user explain the merge better.\n> \n> Will cook in 'next'.\n\nFrom our discussion[1], expect a reroll with the ability to do scissors\ncleanup in messages generated by git-merge. Unfortunately, it'll be a\ncouple of weeks because of finals season.\n\n> \n> * dl/remote-save-to-push (2018-11-13) 1 commit\n> - remote: add --save-to-push option to git remote set-url\n> \n> \"git remote set-url\" learned a new option that moves existing value\n> of the URL field to pushURL field of the remote before replacing\n> the URL field with a new value.\n> \n> I am personally not yet quite convinced if this is worth pursuing.\n\nAny way I could convince you otherwise? I guess this could be rolled\ninto a helper script but it'd be very useful to have the behaviour\nstandardised into the actual remote builtin.\n\n[1]: https://public-inbox.org/git/xmqqin0n44dv.fsf@gitster-ct.c.googlers.com/\n"},{"id":"364880","messageId":"nycvar.QRO.7.76.6.1812092101570.43@tvgsbejvaqbjf.bet","threadId":"49982","inReplyTo":"xmqq8t0z3xcc.fsf@gitster-ct.c.googlers.com","subject":"pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-12-09T20:31:50Z","receivedAt":"2018-12-09T20:31:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Sun, 9 Dec 2018, Junio C Hamano wrote:\n\n> * pw/add-p-select (2018-07-26) 4 commits\n> - add -p: optimize line selection for short hunks\n> - add -p: allow line selection to be inverted\n> - add -p: select modified lines correctly\n> - add -p: select individual hunk lines\n> \n> \"git add -p\" interactive interface learned to let users choose\n> individual added/removed lines to be used in the operation, instead\n> of accepting or rejecting a whole hunk.\n> \n> Will discard.\n> No further feedbacks on the topic for quite some time.\n\nThat is not quite true. I did comment that this feature (which I take as\nbeing inspired by Git GUI's \"Stage Selected Line\"), and thought that it\nwould be useful.\n\nI could imagine, however, that it would make sense for `git add -p` to\nimitate that feature more closely: by allowing to stage a single line and\nthen presenting the current hunk (re-computed) again.\n\nCiao,\nDscho\n"},{"id":"364896","messageId":"xmqqo99u2hjy.fsf@gitster-ct.c.googlers.com","threadId":"49982","inReplyTo":"20181209090300.GA32640@archbookpro.localdomain","subject":"Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-12-10T03:21:05Z","receivedAt":"2018-12-10T03:21:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Denton Liu writes:\n\n> On Sun, Dec 09, 2018 at 05:42:27PM +0900, Junio C Hamano wrote:\n>> * dl/merge-cleanup-scissors-fix (2018-11-21) 2 commits\n>> (merged to 'next' on 2018-11-21 at 217be06acb)\n>> + merge: add scissors line on merge conflict\n>> + t7600: clean up 'merge --squash c3 with c7' test\n>> \n>> The list of conflicted paths shown in the editor while concluding a\n>> conflicted merge was shown above the scissors line when the\n>> clean-up mode is set to \"scissors\", even though it was commented\n>> out just like the list of updated paths and other information to\n>> help the user explain the merge better.\n>> \n>> Will cook in 'next'.\n>\n> From our discussion[1], expect a reroll with the ability to do scissors\n> cleanup in messages generated by git-merge. Unfortunately, it'll be a\n> couple of weeks because of finals season.\n\nOK, I'd imagine that it would be cleaner to do so as a fresh series,\ninstead of incremental updates on top of these two, so let's plan to\neject what we have in 'next' when it happens. Thanks for a heads-up.\n\n>> * dl/remote-save-to-push (2018-11-13) 1 commit\n>> - remote: add --save-to-push option to git remote set-url\n>> \n>> \"git remote set-url\" learned a new option that moves existing value\n>> of the URL field to pushURL field of the remote before replacing\n>> the URL field with a new value.\n>> \n>> I am personally not yet quite convinced if this is worth pursuing.\n>\n> Any way I could convince you otherwise?\n\nI think v3 (which we see above) describes what it wants to do\nclearly enough and implements what it wants to do cleanly. I do not\nthink the patch itself has much room for further improvement.\n\nWhen I re-read the final patch and all the earlier comments I made\nin the thread that began at [*1*], I still do not see in what\npractical workflow and usecase the users would find the feature this\nchange adds useful. \n\nFor each new feature, I want a story we can sell it to the users:\n\"if your workflow is like this or that, you would find yourself\nwanting to do this, which was (impossible|cumbersome) to do before;\nwith this new thing, you can\".\n\nAnd the \"story\" is not \"If you have remote.$name.url and want to\nmove its value to remote.$name.pushurl while setting the former to a\nnew value, then...\" I want to know why the user gets in such a\nsituation in the first place.\n\nTo be helped by the feature, the user\n\n (1) must first have a remote.$name.url (but not remote.$name.pushurl)\n\n (2) that URL must also be usable for pushing\n\n (3) and then has another URL that can be used for fetching\n\n (4) and somehow that new URL is more suitable for fetching than the\n original one.\n\nWhen all of the above holds, then \"set-url --save-to-push\" can be\nused to move the original URL that can be used for both fetching and\npushing to remote.$name.pushurl and set remote.$name.url to the new\nvalue with a single command. But is that a sensible situation to be\nin the first place?\n\nI guess it would help the readers if the documentation (or proposed\nlog message) were more explicit that this is to help the project\noriginator more than the project followers, perhaps. My working\nassumption during the review discussion on this patch has been that\nthere are orders-of-magnitude many project followers who start from\nfetching and locally tweaking without ever publishing than those who\nstart to pushing to a project from day one of joining, or the day\nthey themselves initiated the project. And for these majority\n\"followers\", the first URL is often the one to fetch, which may not\nnecessarily be usable for pushing, and that URL is advertised for\nthe wider general public as the most suitable URL for fetching the\nproject's source. So to these people, neither (2) or (4) would\nhold.\n\nBut for project initiators and those joining a project with write\naccess from day one, the story may be a bit different. They may\nstart with a single URL that can be used for both fetching and\npushing, which means (2) would hold for them, unlike for the\nmajority of users.\n\nI am still not sure what a good example situation is that makes (4)\nhold, though. Perhaps you originally had a R/W URL that always\nrequire authentication, but now you want to use an anonymous R/O URL\nfor your fetch traffic without having to authenticate? If there is\na model situation to make all of these four hold, perhaps it can be\nadded somewhere to help users who would find the new feature useful\ndiscover it.\n\nWithout that, I remain unconvinced.\n\nThanks.\n\n\n[Reference]\n\n*1* https://public-inbox.org/git/1d1b0fe85ddd89cf8172e730e8886d5b4a9ea7eb.1540627720.git.liu.denton@gmail.com/\n"},{"id":"364900","messageId":"20181210035238.GA2104@archbookpro.localdomain","threadId":"49982","inReplyTo":"xmqqo99u2hjy.fsf@gitster-ct.c.googlers.com","subject":"Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2018-12-10T03:52:38Z","receivedAt":"2018-12-10T03:52:43Z","isPatch":false,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"On Mon, Dec 10, 2018 at 12:21:05PM +0900, Junio C Hamano wrote:\n> I think v3 (which we see above) describes what it wants to do\n> clearly enough and implements what it wants to do cleanly. I do not\n> think the patch itself has much room for further improvement.\n> \n> When I re-read the final patch and all the earlier comments I made\n> in the thread that began at [*1*], I still do not see in what\n> practical workflow and usecase the users would find the feature this\n> change adds useful. \n> \n> For each new feature, I want a story we can sell it to the users:\n> \"if your workflow is like this or that, you would find yourself\n> wanting to do this, which was (impossible|cumbersome) to do before;\n> with this new thing, you can\".\n> \n> And the \"story\" is not \"If you have remote.$name.url and want to\n> move its value to remote.$name.pushurl while setting the former to a\n> new value, then...\" I want to know why the user gets in such a\n> situation in the first place.\n> \n> To be helped by the feature, the user\n> \n> (1) must first have a remote.$name.url (but not remote.$name.pushurl)\n> \n> (2) that URL must also be usable for pushing\n> \n> (3) and then has another URL that can be used for fetching\n> \n> (4) and somehow that new URL is more suitable for fetching than the\n> original one.\n> \n> When all of the above holds, then \"set-url --save-to-push\" can be\n> used to move the original URL that can be used for both fetching and\n> pushing to remote.$name.pushurl and set remote.$name.url to the new\n> value with a single command. But is that a sensible situation to be\n> in the first place?\n\nThe following is the story that led to me writing the feature in the\nfirst place:\n\nI have a project that's been developed on my own machine. I want to\ndeploy it onto a server to test, so I use SSH key forwarding and clone\nthe project with the SSH URL onto the server. After fixing some small\nbugs, I'll push the changes directly from the server up. \n\nNow that the server is running, I only touch the repo on the server\noccasionally. I want to pull updates from the main repository without\nnecessarily having to use SSH key forwarding because I might be\nforgetful and forget to start ssh-agent or I might have someone else\nadminister the server who doesn't have key-access to the repository.\nHowever, I also don't want to get rid of my ability to push over SSH so,\nin this case, I'd run \n`git remote set-url --save-to-push origin `.\n\nAlthough it's definitely not an every day activity, I've run into the\nuse case a few times where having this ability would definitely be\nuseful.\n\n> \n> I guess it would help the readers if the documentation (or proposed\n> log message) were more explicit that this is to help the project\n> originator more than the project followers, perhaps. My working\n> assumption during the review discussion on this patch has been that\n> there are orders-of-magnitude many project followers who start from\n> fetching and locally tweaking without ever publishing than those who\n> start to pushing to a project from day one of joining, or the day\n> they themselves initiated the project. And for these majority\n> \"followers\", the first URL is often the one to fetch, which may not\n> necessarily be usable for pushing, and that URL is advertised for\n> the wider general public as the most suitable URL for fetching the\n> project's source. So to these people, neither (2) or (4) would\n> hold.\n> \n> But for project initiators and those joining a project with write\n> access from day one, the story may be a bit different. They may\n> start with a single URL that can be used for both fetching and\n> pushing, which means (2) would hold for them, unlike for the\n> majority of users.\n> \n> I am still not sure what a good example situation is that makes (4)\n> hold, though. Perhaps you originally had a R/W URL that always\n> require authentication, but now you want to use an anonymous R/O URL\n> for your fetch traffic without having to authenticate? If there is\n> a model situation to make all of these four hold, perhaps it can be\n> added somewhere to help users who would find the new feature useful\n> discover it.\n\nIf the above makes sense to you, I can try to distill the use-case down\nto its essence and include it documentation for the patch.\n\n> \n> Without that, I remain unconvinced.\n> \n> Thanks.\n> \n> \n> [Reference]\n> \n> *1* https://public-inbox.org/git/1d1b0fe85ddd89cf8172e730e8886d5b4a9ea7eb.1540627720.git.liu.denton@gmail.com/\n"},{"id":"364914","messageId":"xmqqtvjlisnu.fsf@gitster-ct.c.googlers.com","threadId":"49982","inReplyTo":"20181210035238.GA2104@archbookpro.localdomain","subject":"Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-12-10T10:26:45Z","receivedAt":"2018-12-10T10:26:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Denton Liu writes:\n\n> On Mon, Dec 10, 2018 at 12:21:05PM +0900, Junio C Hamano wrote:\n>\n>> And the \"story\" is not \"If you have remote.$name.url and want to\n>> move its value to remote.$name.pushurl while setting the former to a\n>> new value, then...\" I want to know why the user gets in such a\n>> situation in the first place.\n> ...\n> The following is the story that led to me writing the feature in the\n> first place:\n> ...\n\nOK, so in essense, it is quite similar to the following,\n\n>> .... Perhaps you originally had a R/W URL that always\n>> require authentication, but now you want to use an anonymous R/O URL\n>> for your fetch traffic without having to authenticate? If there is\n>> a model situation to make all of these four hold, perhaps it can be\n>> added somewhere to help users who would find the new feature useful\n>> discover it.\n\ni.e.\n\n\tYou may have started your interaction with the repository\n\twith a single authenticated URL that can be used for both\n\tfetching and pushing, but over time you may have become sick\n\tof having to authenticate only to fetch. In such a case,\n\tyou can feed an unauthenticated/anonymous fetch URL to\n\tset-url with this option, so that the authenticated URL that\n\tyou have been using for pushing becomes the pushURL, and the\n\tnew, unauthenticated/anonymous URL will be used for\n\tfetching.\n\nWith something like that in the documentation, I think the users\nwon't be puzzled by a feature that is seemingly a bit too niche, I\nwould think.\n\nThanks.\n"},{"id":"364915","messageId":"d69259ce-bc45-9201-693b-3902a6379265@talktalk.net","threadId":"49982","inReplyTo":"nycvar.QRO.7.76.6.1812092101570.43@tvgsbejvaqbjf.bet","subject":"Re: pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2018-12-10T10:42:55Z","receivedAt":"2018-12-10T10:43:00Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Dscho\n\nOn 09/12/2018 20:31, Johannes Schindelin wrote:\n> Hi Junio,\n> \n> On Sun, 9 Dec 2018, Junio C Hamano wrote:\n> \n>> * pw/add-p-select (2018-07-26) 4 commits\n>> - add -p: optimize line selection for short hunks\n>> - add -p: allow line selection to be inverted\n>> - add -p: select modified lines correctly\n>> - add -p: select individual hunk lines\n>>\n>> \"git add -p\" interactive interface learned to let users choose\n>> individual added/removed lines to be used in the operation, instead\n>> of accepting or rejecting a whole hunk.\n>>\n>> Will discard.\n>> No further feedbacks on the topic for quite some time.\n> \n> That is not quite true. I did comment that this feature\n\nSorry I meant to reply to that comment but never got round to it.\n\n> (which I take as\n> being inspired by Git GUI's \"Stage Selected Line\"),\n\nnot particularly, I don't use git gui I just wanted a way to easily \nstage a subset of lines without editing the hunk.\n\n> and thought that it would be useful.\n> \n> I could imagine, however, that it would make sense for `git add -p` to\n> imitate that feature more closely: by allowing to stage a single line and\n> then presenting the current hunk (re-computed) again.\n\nthat sounds like it would be quite tedious to stage more than a couple \nof lines, and it could be awkward to get it to stage modified lines \ncorrectly (While I was writing the feature I tried git gui, I think it \nis supposed to be able to stage modified lines correctly but I never \npersuaded it to do it for me. I also tried gitg, tig and hg commit -i \nbut I couldn't get them to do modified lines either)\n\nI'll try and re-roll in the New Year, when does the outreachy project \nfor converting add -i start? - it would be good to try and get this \npinned down before then.\n\nBest Wishes\n\nPhillip\n> Ciao,\n> Dscho\n> \n\n"},{"id":"364966","messageId":"20181210185321.GB37614@google.com","threadId":"49982","inReplyTo":"xmqq8t0z3xcc.fsf@gitster-ct.c.googlers.com","subject":"Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Josh Steadmon","fromEmail":"steadmon@google.com","sentAt":"2018-12-10T18:53:21Z","receivedAt":"2018-12-10T18:53:32Z","isPatch":false,"sender":{"key":"steadmon@google.com","avatar":"https://avatars.githubusercontent.com/u/2654920?v=4"},"body":"On 2018.12.09 17:42, Junio C Hamano wrote:\n> * js/protocol-advertise-multi (2018-11-17) 1 commit\n> - protocol: advertise multiple supported versions\n> \n> The transport layer has been updated so that the protocol version\n> used can be negotiated between the parties, by the initiator\n> listing the protocol versions it is willing to talk, and the other\n> side choosing from one of them.\n> \n> How's the doneness of this one?\n\nI'm not sure if you're asking me specifically or the list in general,\nbut I haven't heard any complaints about this, and there are no\noutstanding requests on the review thread.\n\n\n> * js/smart-http-detect-remote-error (2018-11-17) 3 commits\n> (merged to 'next' on 2018-11-18 at 5c6edfcb85)\n> + remote-curl: die on server-side errors\n> + remote-curl: tighten \"version 2\" check for smart-http\n> + remote-curl: refactor smart-http discovery\n> \n> Some errors from the other side coming over smart HTTP transport\n> were not noticed, which has been corrected.\n> \n> Will cook in 'next'.\n\nMasaya had a series that addresses this as well:\nhttps://public-inbox.org/git/20181127045301.103807-1-masayasuzuki@google.com/\n\nTo combine these, we'd want to drop the diff to remote-curl.c in the\nfinal patch of this series.\n"},{"id":"364973","messageId":"CABPp-BGVHnaZLg4fuptVmNa=jRHg0cMDTWjv1NdLQJXPe=+ahw@mail.gmail.com","threadId":"49982","inReplyTo":"xmqq8t0z3xcc.fsf@gitster-ct.c.googlers.com","subject":"Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-12-10T20:05:10Z","receivedAt":"2018-12-10T20:05:25Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sun, Dec 9, 2018 at 12:42 AM Junio C Hamano wrote:\n\n> Git 2.20 has been tagged. I'd expect that we would slow down to see\n> how stable it is and queue only the brown-paper-bag fixes for a week\n> or so, before opening the tree for the next cycle, rewinding the tip\n> of 'next', etc.\n\nDoes this mean you'd prefer we continue to wait a little longer before\nsending in new series and re-rolls, or just that you are managing\nexpectations about when they might be queued?\n\n(Just curious whether I should submit my rebase-merge-on-sequencer\nre-roll or continue waiting. I'm happy to do whatever is more\nconvenient for others.)\n"},{"id":"364979","messageId":"875zw1aw68.fsf@evledraar.gmail.com","threadId":"49982","inReplyTo":"CABPp-BGVHnaZLg4fuptVmNa=jRHg0cMDTWjv1NdLQJXPe=+ahw@mail.gmail.com","subject":"Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-12-10T21:50:23Z","receivedAt":"2018-12-10T21:50:28Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Dec 10 2018, Elijah Newren wrote:\n\n> On Sun, Dec 9, 2018 at 12:42 AM Junio C Hamano wrote:\n>\n>> Git 2.20 has been tagged. I'd expect that we would slow down to see\n>> how stable it is and queue only the brown-paper-bag fixes for a week\n>> or so, before opening the tree for the next cycle, rewinding the tip\n>> of 'next', etc.\n>\n> Does this mean you'd prefer we continue to wait a little longer before\n> sending in new series and re-rolls, or just that you are managing\n> expectations about when they might be queued?\n>\n> (Just curious whether I should submit my rebase-merge-on-sequencer\n> re-roll or continue waiting. I'm happy to do whatever is more\n> convenient for others.)\n\nRelated; Junio: I've submitted a few things in the last 2-3 weeks which\nI knew weren't making it into 2.20, but I just wanted to kick out the\ndoor as I had them ready. Things which are not noted in this \"What's\nCooking\".\n\nI'm fine with re-submitting those once 2.21 picks up, but don't want to\nneedlessly spam if your plan is to circle around and pick up those\nthings you were (rightly) ignoring during the RC period.\n"},{"id":"365005","messageId":"xmqqwoogn8ha.fsf@gitster-ct.c.googlers.com","threadId":"49982","inReplyTo":"20181210185321.GB37614@google.com","subject":"Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-12-11T01:43:45Z","receivedAt":"2018-12-11T01:43:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josh Steadmon writes:\n\n> On 2018.12.09 17:42, Junio C Hamano wrote:\n>> * js/protocol-advertise-multi (2018-11-17) 1 commit\n>> - protocol: advertise multiple supported versions\n>> \n>> The transport layer has been updated so that the protocol version\n>> used can be negotiated between the parties, by the initiator\n>> listing the protocol versions it is willing to talk, and the other\n>> side choosing from one of them.\n>> \n>> How's the doneness of this one?\n>\n> I'm not sure if you're asking me specifically or the list in general,\n> but I haven't heard any complaints about this, and there are no\n> outstanding requests on the review thread.\n\nIt is both but more of the latter ;-) \"I haven't seen any problem\nreported, and all review comments have been addressed\" by you is\nalso a welcome feedback.\n\n>> * js/smart-http-detect-remote-error (2018-11-17) 3 commits\n>> (merged to 'next' on 2018-11-18 at 5c6edfcb85)\n>> + remote-curl: die on server-side errors\n>> + remote-curl: tighten \"version 2\" check for smart-http\n>> + remote-curl: refactor smart-http discovery\n>> \n>> Some errors from the other side coming over smart HTTP transport\n>> were not noticed, which has been corrected.\n>> \n>> Will cook in 'next'.\n>\n> Masaya had a series that addresses this as well:\n> https://public-inbox.org/git/20181127045301.103807-1-masayasuzuki@google.com/\n>\n> To combine these, we'd want to drop the diff to remote-curl.c in the\n> final patch of this series.\n\nOK, I'll kick the topic out of 'next' when reopening the tree for\nthe next cycle. Could you work with him to feed me the result of\ncombined effort to replace these three patches? Thanks.\n"},{"id":"365006","messageId":"xmqqsgz4n89k.fsf@gitster-ct.c.googlers.com","threadId":"49982","inReplyTo":"CABPp-BGVHnaZLg4fuptVmNa=jRHg0cMDTWjv1NdLQJXPe=+ahw@mail.gmail.com","subject":"Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-12-11T01:48:23Z","receivedAt":"2018-12-11T01:48:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren writes:\n\n> On Sun, Dec 9, 2018 at 12:42 AM Junio C Hamano wrote:\n>\n>> Git 2.20 has been tagged. I'd expect that we would slow down to see\n>> how stable it is and queue only the brown-paper-bag fixes for a week\n>> or so, before opening the tree for the next cycle, rewinding the tip\n>> of 'next', etc.\n>\n> Does this mean you'd prefer we continue to wait a little longer before\n> sending in new series and re-rolls, or just that you are managing\n> expectations about when they might be queued?\n\nMore of the latter. The best way to find bugs that matter in real\nlife is to use the software in the real project settings, i.e. you\nguys work on your own topics using Git. I'll keep reviewing and\ncommenting just like other reviewers, but the new patches won't come\nclose to 'next' (as I said elsewhere, being in 'pu' does not count\nmuch---it is like getting bookmarked) in the meantime.\n\n"},{"id":"365007","messageId":"xmqqo99sn875.fsf@gitster-ct.c.googlers.com","threadId":"49982","inReplyTo":"875zw1aw68.fsf@evledraar.gmail.com","subject":"Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-12-11T01:49:50Z","receivedAt":"2018-12-11T01:49:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> Related; Junio: I've submitted a few things in the last 2-3 weeks which\n> I knew weren't making it into 2.20, but I just wanted to kick out the\n> door as I had them ready. Things which are not noted in this \"What's\n> Cooking\".\n>\n> I'm fine with re-submitting those once 2.21 picks up, but don't want to\n> needlessly spam if your plan is to circle around and pick up those\n> things you were (rightly) ignoring during the RC period.\n\nPlease consider it a time to get things reviewed by each other and a\nchance to polish them before they even hit 'pu'.\n"},{"id":"365010","messageId":"CAGZ79kZrYP05=eSx4=09Y9Nx9pNMyyKz=tGXjueuhVgJo=Z5bQ@mail.gmail.com","threadId":"49982","inReplyTo":"xmqq8t0z3xcc.fsf@gitster-ct.c.googlers.com","subject":"Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-12-11T02:00:30Z","receivedAt":"2018-12-11T02:00:45Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"> * sb/more-repo-in-api (2018-11-14) 23 commits\n> (merged to 'next' on 2018-11-19 at e5d2a129da)\n> [..]\n> The in-core repository instances are passed through more codepaths.\n>\n> Will cook in 'next'.\n> cf. <20181115221254.45373-1-jonathantanmy@google.com>\n\nLooking into that.\n\n> * sb/submodule-recursive-fetch-gets-the-tip (2018-12-09) 9 commits\n> [..]\n> \"git fetch --recurse-submodules\" may not fetch the necessary commit\n> that is bound to the superproject, which is getting corrected.\n>\n> Ready?\n\nI saw you picked up the latest iteration of the last patch at\nhttps://public-inbox.org/git/20181206212655.145586-1-sbeller@google.com/\nwhich has received no review comments, yet, and you seem to have\njust taken it for replacement without looking closely.\n\nI think it is ready, but I seem to be an optimist at times\nwhen it comes to my own code. :-)\n"},{"id":"365041","messageId":"xmqq8t0wlh7y.fsf@gitster-ct.c.googlers.com","threadId":"49982","inReplyTo":"CAGZ79kZrYP05=eSx4=09Y9Nx9pNMyyKz=tGXjueuhVgJo=Z5bQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-12-11T06:17:53Z","receivedAt":"2018-12-11T06:17:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> I saw you picked up the latest iteration of the last patch at\n> https://public-inbox.org/git/20181206212655.145586-1-sbeller@google.com/\n> which has received no review comments, yet, and you seem to have\n> just taken it for replacement without looking closely.\n\nWhat's there in 'pu' does not even count as getting \"picked up\".\nNear the tip of 'pu' outside 'next' is merely serving as a bookmark\nso that I do not have to hunt around in the list archive after\npeople comment on the patches.\n\n> I think it is ready, but I seem to be an optimist at times\n> when it comes to my own code. :-)\n\nOh, who isn't?\n"},{"id":"365050","messageId":"nycvar.QRO.7.76.6.1812111049560.43@tvgsbejvaqbjf.bet","threadId":"49982","inReplyTo":"d69259ce-bc45-9201-693b-3902a6379265@talktalk.net","subject":"Re: pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-12-11T09:56:57Z","receivedAt":"2018-12-11T09:57:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Phillip,\n\n[Cc:ing Slavica, the Outreachy intern working on converting `add -i` to a\nbuilt-in]\n\nOn Mon, 10 Dec 2018, Phillip Wood wrote:\n\n> On 09/12/2018 20:31, Johannes Schindelin wrote:\n> > \n> > On Sun, 9 Dec 2018, Junio C Hamano wrote:\n> > \n> > > * pw/add-p-select (2018-07-26) 4 commits\n> > > - add -p: optimize line selection for short hunks\n> > > - add -p: allow line selection to be inverted\n> > > - add -p: select modified lines correctly\n> > > - add -p: select individual hunk lines\n> > >\n> > > \"git add -p\" interactive interface learned to let users choose\n> > > individual added/removed lines to be used in the operation, instead\n> > > of accepting or rejecting a whole hunk.\n> > >\n> > > Will discard.\n> > > No further feedbacks on the topic for quite some time.\n> > \n> > That is not quite true. I did comment that this feature\n> \n> Sorry I meant to reply to that comment but never got round to it.\n\nNo worries. We're all busy down here.\n\n> > (which I take as being inspired by Git GUI's \"Stage Selected Line\"),\n> \n> not particularly, I don't use git gui I just wanted a way to easily\n> stage a subset of lines without editing the hunk.\n\nOkay. I used to use Git GUI quite a bit to stage individual lines, but\nrecently I tried to stay more in the terminal and used the `split` and\n`edit` commands of `add -p` quite extensively. Wishing for an quicker way\nto stage individual lines between all of my debug print statements.\n\n> > and thought that it would be useful.\n> > \n> > I could imagine, however, that it would make sense for `git add -p` to\n> > imitate that feature more closely: by allowing to stage a single line\n> > and then presenting the current hunk (re-computed) again.\n> \n> that sounds like it would be quite tedious to stage more than a couple\n> of lines,\n\nIt would be. But then, if you want to do anything slightly more\ncomplicated than staging a hunk or a line, I personally prefer the `edit`\ncommand *a lot*, as it lets me even split unrelated changes in the same\nline into two commits.\n\n> and it could be awkward to get it to stage modified lines correctly\n> (While I was writing the feature I tried git gui, I think it is supposed\n> to be able to stage modified lines correctly but I never persuaded it to\n> do it for me. I also tried gitg, tig and hg commit -i but I couldn't get\n> them to do modified lines either)\n\nGit GUI works very reliably for me, but then, I have Git for Windows'\npatched Git GUI at my finger tips (oh how I wish we had a Git GUI\nmaintainer again).\n\nIt should not be awkward to stage a single modified line at all.\nEssentially, you take the hunk, strip out all `-` and `+` lines except the\none you want to stage, then stage that with `git apply --cached\n--recount`, and then you simply re-generate that hunk.\n\n> I'll try and re-roll in the New Year, when does the outreachy project\n> for converting add -i start? - it would be good to try and get this\n> pinned down before then.\n\nToo late. Slavica started on December 4th, and you can even read about it\non their blog: https://slavicadj.github.io/blog/\n\nCiao,\nDscho\n"},{"id":"365082","messageId":"be3d2a6e-e960-6e43-17bf-9f67837f74e5@talktalk.net","threadId":"49982","inReplyTo":"nycvar.QRO.7.76.6.1812111049560.43@tvgsbejvaqbjf.bet","subject":"Re: pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2018-12-11T14:48:03Z","receivedAt":"2018-12-11T14:48:08Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Dscho and Slavica\n\nOn 11/12/2018 09:56, Johannes Schindelin wrote:\n> Hi Phillip,\n> \n> [Cc:ing Slavica, the Outreachy intern working on converting `add -i` to a\n> built-in]\n> \n> On Mon, 10 Dec 2018, Phillip Wood wrote:\n> \n>> On 09/12/2018 20:31, Johannes Schindelin wrote:\n>>>\n\n\n\n>>> (which I take as being inspired by Git GUI's \"Stage Selected Line\"),\n>>\n>> not particularly, I don't use git gui I just wanted a way to easily\n>> stage a subset of lines without editing the hunk.\n> \n> Okay. I used to use Git GUI quite a bit to stage individual lines, but\n> recently I tried to stay more in the terminal and used the `split` and\n> `edit` commands of `add -p` quite extensively. Wishing for an quicker way\n> to stage individual lines between all of my debug print statements.\n\nYes that's one of my main uses for selective staging as well\n\n>>> and thought that it would be useful.\n>>>\n>>> I could imagine, however, that it would make sense for `git add -p` to\n>>> imitate that feature more closely: by allowing to stage a single line\n>>> and then presenting the current hunk (re-computed) again.\n>>\n>> that sounds like it would be quite tedious to stage more than a couple\n>> of lines,\n> \n> It would be. But then, if you want to do anything slightly more\n> complicated than staging a hunk or a line, I personally prefer the `edit`\n> command *a lot*, as it lets me even split unrelated changes in the same\n> line into two commits.\n\nI was hoping for something simpler than editing patches just to stage a \nsubset of lines that do not need to be edited.\n\n>> and it could be awkward to get it to stage modified lines correctly\n>> (While I was writing the feature I tried git gui, I think it is supposed\n>> to be able to stage modified lines correctly but I never persuaded it to\n>> do it for me. I also tried gitg, tig and hg commit -i but I couldn't get\n>> them to do modified lines either)\n> \n> Git GUI works very reliably for me, but then, I have Git for Windows'\n> patched Git GUI at my finger tips (oh how I wish we had a Git GUI\n> maintainer again).\n> \n> It should not be awkward to stage a single modified line at all.\n> Essentially, you take the hunk, strip out all `-` and `+` lines except the\n> one you want to stage, then stage that with `git apply --cached\n> --recount`, and then you simply re-generate that hunk.\n\nBut that involves editing the hunk or have I misunderstood? The aim of \nmy series was that you'd select the '-' & '+' lines for the modification \nand it would stage them properly as a modification so given\n\n1 -a\n2 -b\n3 +c\n\nselecting 1,3 would stage\n\n-a\n+c\n b\n\nnot\n\n-a\n b\n+c\n\n(see https://public-inbox.org/git/878ta8vyqe.fsf@evledraar.gmail.com/ \nfor the background)\n\n>> I'll try and re-roll in the New Year, when does the outreachy project\n>> for converting add -i start? - it would be good to try and get this\n>> pinned down before then.\n> \n> Too late. Slavica started on December 4th, and you can even read about it\n> on their blog: https://slavicadj.github.io/blog/\n\nThanks for the link and hello Slavica! - I look forward to reading your \npatches when you post them here.\n\nBest Wishes\n\nPhillip\n"},{"id":"365464","messageId":"fcc4ad0b-5566-165c-f20d-8a09ce659112@gmail.com","threadId":"49982","inReplyTo":"xmqq8t0z3xcc.fsf@gitster-ct.c.googlers.com","subject":"Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Alban Gruin","fromEmail":"alban.gruin@gmail.com","sentAt":"2018-12-16T21:48:31Z","receivedAt":"2018-12-16T21:48:40Z","isPatch":false,"sender":{"key":"alban.gruin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6310153?v=4"},"body":"Hi Junio,\n\nLe 09/12/2018 à 09:42, Junio C Hamano a écrit :> -%<-\n> * ag/sequencer-reduce-rewriting-todo (2018-11-12) 16 commits\n> . rebase--interactive: move transform_todo_file() to\nrebase--interactive.c\n> . sequencer: fix a call to error() in transform_todo_file()\n> . sequencer: use edit_todo_list() in complete_action()\n> . rebase-interactive: rewrite edit_todo_list() to handle the initial edit\n> . rebase-interactive: append_todo_help() changes\n> . rebase-interactive: use todo_list_write_to_file() in edit_todo_list()\n> . sequencer: refactor skip_unnecessary_picks() to work on a todo_list\n> . sequencer: change complete_action() to use the refactored functions\n> . sequencer: make sequencer_make_script() write its script to a strbuf\n> . sequencer: refactor rearrange_squash() to work on a todo_list\n> . sequencer: refactor sequencer_add_exec_commands() to work on a\ntodo_list\n> . sequencer: refactor check_todo_list() to work on a todo_list\n> . sequencer: introduce todo_list_write_to_file()\n> . sequencer: refactor transform_todos() to work on a todo_list\n> . sequencer: make the todo_list structure public\n> . sequencer: changes in parse_insn_buffer()\n>\n> The scripted version of \"git rebase -i\" wrote and rewrote the todo\n> list many times during a single step of its operation, and the\n> recent C-rewrite made a faithful conversion of the logic to C. The\n> implementation has been updated to carry necessary information\n> around in-core to avoid rewriting the same file over and over\n> unnecessarily.\n>\n> With too many topics in-flight that touch sequencer and rebaser,\n> this need to wait giving precedence to other topics that fix bugs.\n>\n\nIf I’m not mistaken, there is currently 3 others series touching rebase,\nrebase-interactive and/or the sequencer: en/rebase-merge-on-sequencer,\nnd/the-index, and the new js/rebase-i-redo-exec. Among these, I believe\nonly nd/the-index actually touches the same places as\nag/sequencer-reduce-rewriting-todo, and is not a behaviour change.\n\nIs this safe to reroll this in the next few days?\n\n--\nAlban\n\n"},{"id":"367257","messageId":"nycvar.QRO.7.76.6.1901212154300.41@tvgsbejvaqbjf.bet","threadId":"49982","inReplyTo":"be3d2a6e-e960-6e43-17bf-9f67837f74e5@talktalk.net","subject":"Re: pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-01-21T20:58:02Z","receivedAt":"2019-01-21T20:58:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Phillip,\n\n\nOn Tue, 11 Dec 2018, Phillip Wood wrote:\n\n> On 11/12/2018 09:56, Johannes Schindelin wrote:\n> \n> > On Mon, 10 Dec 2018, Phillip Wood wrote:\n> > \n> > > On 09/12/2018 20:31, Johannes Schindelin wrote:\n> > >\n> > > > I could imagine, however, that it would make sense for `git add\n> > > > -p` to imitate that feature more closely: by allowing to stage a\n> > > > single line and then presenting the current hunk (re-computed)\n> > > > again.\n> > >\n> > > that sounds like it would be quite tedious to stage more than a\n> > > couple of lines,\n> > \n> > It would be. But then, if you want to do anything slightly more\n> > complicated than staging a hunk or a line, I personally prefer the\n> > `edit` command *a lot*, as it lets me even split unrelated changes in\n> > the same line into two commits.\n> \n> I was hoping for something simpler than editing patches just to stage a\n> subset of lines that do not need to be edited.\n\nPersonally, I found that Git GUI's \"Stage selected lines\" worked well,\neven if I could only mark consecutive lines. That might be a valuable\nsimplification in your case, too, to allow either individual lines to be\nstaged, or alternatively a simple start-end range.\n\nThe trick, of course, is to present the updated hunk after staging the\nline(s)... That's what makes it so fun to use in Git GUI.\n\n> > > and it could be awkward to get it to stage modified lines correctly\n> > > (While I was writing the feature I tried git gui, I think it is\n> > > supposed to be able to stage modified lines correctly but I never\n> > > persuaded it to do it for me. I also tried gitg, tig and hg commit\n> > > -i but I couldn't get them to do modified lines either)\n> > \n> > Git GUI works very reliably for me, but then, I have Git for Windows'\n> > patched Git GUI at my finger tips (oh how I wish we had a Git GUI\n> > maintainer again).\n> > \n> > It should not be awkward to stage a single modified line at all.\n> > Essentially, you take the hunk, strip out all `-` and `+` lines except\n> > the one you want to stage, then stage that with `git apply --cached\n> > --recount`, and then you simply re-generate that hunk.\n> \n> But that involves editing the hunk or have I misunderstood? The aim of\n> my series was that you'd select the '-' & '+' lines for the modification\n> and it would stage them properly as a modification so given\n> \n> 1 -a\n> 2 -b\n> 3 +c\n> \n> selecting 1,3 would stage\n> \n> -a\n> +c\n> b\n> \n> not\n> \n> -a\n> b\n> +c\n> \n> (see https://public-inbox.org/git/878ta8vyqe.fsf@evledraar.gmail.com/\n> for the background)\n\nWhy not staging them as line 1 first, then seeing an updated hunk and\nstaging the next one? That's an easier UI to begin with.\n\nCiao,\nDscho\n"},{"id":"367353","messageId":"64557c5b-8a91-2a01-fa98-5a5d8b90e49f@talktalk.net","threadId":"49982","inReplyTo":"nycvar.QRO.7.76.6.1901212154300.41@tvgsbejvaqbjf.bet","subject":"Re: pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2019-01-22T20:27:04Z","receivedAt":"2019-01-22T20:27:10Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Dscho\n\nOn 21/01/2019 20:58, Johannes Schindelin wrote:\n> Hi Phillip,\n> \n> \n> On Tue, 11 Dec 2018, Phillip Wood wrote:\n> \n>> On 11/12/2018 09:56, Johannes Schindelin wrote:\n>>\n>>> On Mon, 10 Dec 2018, Phillip Wood wrote:\n>>>\n>>>> On 09/12/2018 20:31, Johannes Schindelin wrote:\n>>>>\n>>>>> I could imagine, however, that it would make sense for `git add\n>>>>> -p` to imitate that feature more closely: by allowing to stage a\n>>>>> single line and then presenting the current hunk (re-computed)\n>>>>> again.\n>>>>\n>>>> that sounds like it would be quite tedious to stage more than a\n>>>> couple of lines,\n>>>\n>>> It would be. But then, if you want to do anything slightly more\n>>> complicated than staging a hunk or a line, I personally prefer the\n>>> `edit` command *a lot*, as it lets me even split unrelated changes in\n>>> the same line into two commits.\n>>\n>> I was hoping for something simpler than editing patches just to stage a\n>> subset of lines that do not need to be edited.\n> \n> Personally, I found that Git GUI's \"Stage selected lines\" worked well,\n> even if I could only mark consecutive lines. That might be a valuable\n> simplification in your case, too, to allow either individual lines to be\n> staged, or alternatively a simple start-end range.\n> \n> The trick, of course, is to present the updated hunk after staging the\n> line(s)... That's what makes it so fun to use in Git GUI.\n> \n>>>> and it could be awkward to get it to stage modified lines correctly\n>>>> (While I was writing the feature I tried git gui, I think it is\n>>>> supposed to be able to stage modified lines correctly but I never\n>>>> persuaded it to do it for me. I also tried gitg, tig and hg commit\n>>>> -i but I couldn't get them to do modified lines either)\n>>>\n>>> Git GUI works very reliably for me, but then, I have Git for Windows'\n>>> patched Git GUI at my finger tips (oh how I wish we had a Git GUI\n>>> maintainer again).\n>>>\n>>> It should not be awkward to stage a single modified line at all.\n>>> Essentially, you take the hunk, strip out all `-` and `+` lines except\n>>> the one you want to stage, then stage that with `git apply --cached\n>>> --recount`, and then you simply re-generate that hunk.\n>>\n>> But that involves editing the hunk or have I misunderstood? The aim of\n>> my series was that you'd select the '-' & '+' lines for the modification\n>> and it would stage them properly as a modification so given\n>>\n>> 1 -a\n>> 2 -b\n>> 3 +c\n>>\n>> selecting 1,3 would stage\n>>\n>> -a\n>> +c\n>> b\n>>\n>> not\n>>\n>> -a\n>> b\n>> +c\n>>\n>> (see https://public-inbox.org/git/878ta8vyqe.fsf@evledraar.gmail.com/\n>> for the background)\n> \n> Why not staging them as line 1 first, then seeing an updated hunk and\n> staging the next one? That's an easier UI to begin with.\n\nIf you stage line 1 first then the hunk would look like\n\n1 -b\n2 +c\n\nIf you then select line 2 you end up with\n\n b\n+c\n\nWhich is not what you want if you're trying to stage the modified line a \n-> c. git-gui has some magic to get around this [1] but I found it hard \nto use when I tried it out a while ago - I think you have to stage the \nlines in a particular order for it to work.\n\n[1] \nhttps://repo.or.cz/git-gui.git/commit/c7f7457026dc2f6979842f81cc17098579fec8d8\n\nBest Wishes\n\nPhillip\n\n> \n> Ciao,\n> Dscho\n> \n\n"}]}