{"thread":{"id":"54218","subject":"What's cooking in git.git (Sep 2020, #03; Wed, 9)","startedAt":"2020-09-09T22:32:55Z","lastAt":"2020-09-15T22:55:01Z","messageCount":13,"participants":["Junio C Hamano","Eric Sunshine","Jakub Narębski","Taylor Blau"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"405293","messageId":"xmqq4ko6twc9.fsf@gitster.c.googlers.com","threadId":"54218","inReplyTo":null,"subject":"What's cooking in git.git (Sep 2020, #03; Wed, 9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-09T22:32:38Z","receivedAt":"2020-09-09T22:32:55Z","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 '-' are\nonly in 'seen' (formerly 'pu'---proposed updates) while commits prefixed\nwith '+' are in 'next'. The ones marked with '.' do not appear in any of\nthe integration branches, but I am still holding onto them.\n\nYou can find the changes described here in the integration branches of the\nrepositories listed at\n\n http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[Graduated to 'master']\n\n* es/worktree-repair (2020-08-31) 5 commits\n (merged to 'next' on 2020-08-31 at 604825c5e4)\n + init: make --separate-git-dir work from within linked worktree\n + init: teach --separate-git-dir to repair linked worktrees\n + worktree: teach \"repair\" to fix outgoing links to worktrees\n + worktree: teach \"repair\" to fix worktree back-links to main worktree\n + worktree: add skeleton \"repair\" command\n\n \"git worktree\" gained a \"repair\" subcommand to help users recover\n after moving the worktrees or repository manually without telling\n Git. Also, \"git init --separate-git-dir\" no longer corrupts\n administrative data related to linked worktrees.\n\n\n* hv/ref-filter-misc (2020-08-28) 8 commits\n (merged to 'next' on 2020-09-02 at 9a8bb84f20)\n + ref-filter: add `sanitize` option for 'subject' atom\n + pretty: refactor `format_sanitized_subject()`\n + ref-filter: add `short` modifier to 'parent' atom\n + ref-filter: add `short` modifier to 'tree' atom\n + ref-filter: rename `objectname` related functions and fields\n + ref-filter: modify error messages in `grab_objectname()`\n + ref-filter: refactor `grab_objectname()`\n + ref-filter: support different email formats\n\n The \"--format=\" option to the \"for-each-ref\" command and friends\n learned a few more tricks, e.g. the \":short\" suffix that applies to\n \"objectname\" now also can be used for \"parent\", \"tree\", etc.\n\n\n* jk/worktree-check-clean-leakfix (2020-08-27) 1 commit\n (merged to 'next' on 2020-08-31 at 220fc43629)\n + worktree: fix leak in check_clean_worktree()\n\n Leakfix.\n\n\n* js/ci-squelch-false-failure (2020-09-02) 2 commits\n (merged to 'next' on 2020-09-03 at 254f390305)\n + ci: avoid ugly \"failure\" in the `ci-config` job\n + ci: fix indentation of the `ci-config` job\n\n CI noise reduction.\n\n\n* jt/interpret-branch-name-fallback (2020-09-02) 3 commits\n (merged to 'next' on 2020-09-03 at 28914ab788)\n + wt-status: tolerate dangling marks\n + refs: move dwim_ref() to header file\n + sha1-name: replace unsigned int with option struct\n\n \"git status\" has trouble showing where it came from by interpreting\n reflog entries that recordcertain events, e.g. \"checkout @{u}\", and\n gives a hard/fatal error. Even though it inherently is impossible\n to give a correct answer because the reflog entries lose some\n information (e.g. \"@{u}\" does not record what branch the user was\n on hence which branch 'the upstream' needs to be computed, and even\n if the record were available, the relationship between branches may\n have changed), at least hide the error to allow \"status\" show its\n output.\n\n\n* os/vcbuild (2020-09-08) 3 commits\n (merged to 'next' on 2020-09-08 at 56551401c2)\n + contrib/buildsystems: fix expat library name for generated vcxproj\n (merged to 'next' on 2020-09-03 at 0216ec9cb9)\n + vcbuild: fix batch file name in README\n + vcbuild: fix library name for expat with make MSVC=1\n\n Fix build procedure for MSVC.\n\n\n* pb/imap-send-updates (2020-08-31) 3 commits\n (merged to 'next' on 2020-09-02 at 899fca3919)\n + git-imap-send.txt: add note about localized Gmail folders\n + git-imap-send.txt: do verify SSL certificate for gmail.com\n + git-imap-send.txt: don't duplicate 'Examples' sections\n\n \"git imap-send\" updates.\n\n\n* so/separate-field-for-m-and-diff-merges (2020-08-31) 1 commit\n (merged to 'next' on 2020-08-31 at 8def2984ca)\n + revision: add separate field for \"-m\" of \"diff-index -m\"\n\n Internal API clean-up to handle two options \"diff-index\" and \"log\"\n have, which happen to share the same short form, more sensibly.\n\n\n* ss/submodule-summary-in-c (2020-08-12) 4 commits\n (merged to 'next' on 2020-08-17 at 9bc352cb70)\n + submodule: port submodule subcommand 'summary' from shell to C\n + t7421: introduce a test script for verifying 'summary' output\n + submodule: rename helper functions to avoid ambiguity\n + submodule: remove extra line feeds between callback struct and macro\n (this branch is used by ss/submodule-summary-in-c-fixes.)\n\n Yet another subcommand of \"git submodule\" is getting rewritten in C.\n\n\n* ss/submodule-summary-in-c-fixes (2020-08-27) 3 commits\n (merged to 'next' on 2020-09-02 at 7f959811b8)\n + t7421: eliminate 'grep' check in t7421.4 for mingw compatibility\n + submodule: fix style in function definition\n + submodule: eliminate unused parameters from print_submodule_summary()\n (this branch uses ss/submodule-summary-in-c.)\n\n Fixups to a topic in 'next'.\n\n\n* tb/repack-clearing-midx (2020-08-28) 2 commits\n (merged to 'next' on 2020-08-28 at 4204c0cb5e)\n + midx: traverse the local MIDX first\n (merged to 'next' on 2020-08-27 at a465875cbb)\n + builtin/repack.c: invalidate MIDX only when necessary\n\n When a packfile is removed by \"git repack\", multi-pack-index gets\n cleared; the code was taught to do so less aggressively by first\n checking if the midx actually refers to a pack that no longer\n exists.\n\n--------------------------------------------------\n[New Topics]\n\n* al/t3200-back-on-a-branch (2020-09-08) 1 commit\n (merged to 'next' on 2020-09-09 at 833e2fc60c)\n + t3200: clean side effect of git checkout --orphan\n\n Test fix.\n\n Will merge to 'master'.\n\n\n* bc/rev-parse-path-format (2020-09-08) 1 commit\n - rev-parse: add option for absolute or relative path formatting\n\n \"git rev-parse\" can be explicitly told to give output as absolute\n or relative path.\n\n\n* ds/maintenance-part-3 (2020-09-06) 6 commits\n - maintenance: recommended schedule in register/start\n - maintenance: add start/stop subcommands\n - maintenance: add [un]register subcommands\n - for-each-repo: run subcommands on configured repos\n - maintenance: add --schedule option and config\n - maintenance: optionally skip --auto process\n (this branch uses ds/maintenance-part-1 and ds/maintenance-part-2.)\n\n Parts of \"git maintenance\" to ease writing crontab entries (and\n other scheduling system configuration) for it.\n\n\n* ea/blame-use-oideq (2020-09-08) 1 commit\n (merged to 'next' on 2020-09-09 at babefe4727)\n + blame.c: replace instance of !oidcmp for oideq\n\n Code cleanup.\n\n Will merge to 'master'.\n\n\n* es/format-patch-interdiff-cleanup (2020-09-08) 3 commits\n - format-patch: use 'origin' as start of current-series-range when known\n - diff-lib: tighten show_interdiff()'s interface\n - diff: move show_interdiff() from its own file to diff-lib\n\n Code cleanup with a slight behaviour change when \"format-patch\n --range-diff= origin..HEAD\" gives a single revision to\n .\n\n Will merge to 'next'.\n\n\n* es/wt-add-detach (2020-09-06) 3 commits\n - git-worktree.txt: discuss branch-based vs. throwaway worktrees\n - worktree: teach `add` to recognize -d as shorthand for --detach\n - git-checkout.txt: document -d short option for --detach\n\n \"git worktree add\" learns the \"--detach\" option to create a new\n worktree without being on a branch.\n\n Will merge to 'next'.\n\n\n* hn/refs-ref-log-only-bit (2020-09-08) 1 commit\n (merged to 'next' on 2020-09-09 at f729cb2c81)\n + refs: move REF_LOG_ONLY to refs-internal.h\n\n A bit of API reshuffling to make sure stuff common to all backends\n are not defined only in files backend.\n\n Will merge to 'master'.\n\n\n* jc/add-i-use-builtin-experimental (2020-09-08) 1 commit\n (merged to 'next' on 2020-09-09 at abcb7515dc)\n + add -i: use the built-in version when feature.experimental is set\n\n The \"add -i/-p\" machinery has been written in C but it is not used\n by default yet. It is made default to those who are participating\n in feature.experimental experiment.\n\n Will merge to 'master'.\n\n\n* jc/quote-path-cleanup (2020-09-08) 6 commits\n - quote: turn 'nodq' parameter into a set of flags\n - quote: rename misnamed sq_lookup[] to cq_lookup[]\n - wt-status: consistently quote paths in \"status --short\" output\n - quote_path: optionally allow quoting a path with SP in it\n - quote_path: give flags parameter to quote_path()\n - quote_path: rename quote_path_relative() to quote_path()\n\n \"git status --short\" quoted a path with SP in it when tracked, but\n not those that are untracked, ignored or unmerged. They are all\n shown quoted consistently.\n\n Undecided.\n This is more involved than alternatives proposed by brian and Réne\n and I am not sure extra changes to the codebase is a net positive.\n cf. <20200908013013.1099937-1-sandals@crustytoothpaste.net>\n cf. <3a72c5f2-35cc-a865-d5f2-02706c48d8ec@web.de>\n\n\n* jk/add-i-fixes (2020-09-08) 2 commits\n (merged to 'next' on 2020-09-09 at 46ea071a7a)\n + add--interactive.perl: specify --no-color explicitly\n + add-patch: fix inverted return code of repo_read_index()\n\n \"add -i/-p\" fixes.\n\n Will merge to 'master'.\n\n\n* os/collect-changed-submodules-optim (2020-09-06) 1 commit\n - submodule: suppress checking for file name and ref ambiguity for object ids\n\n Optimization around submodule handling.\n\n Will merge to 'next'.\n\n\n* os/fetch-submodule-optim (2020-09-06) 1 commit\n - fetch: do not look for submodule changes in unchanged refs\n\n Optimization around submodule handling.\n\n Will merge to 'next'.\n\n\n* pw/add-p-edit-ita-path (2020-09-09) 1 commit\n - add -p: fix editing of intent-to-add paths\n\n \"add -p\" did not allow editing paths that were only added in\n intent.\n\n Will merge to 'next'.\n\n\n* pw/add-p-leakfix (2020-09-08) 1 commit\n (merged to 'next' on 2020-09-09 at 4206d0503c)\n + add -p: fix memory leak\n\n Leakfix.\n\n Will merge to 'master'.\n\n\n* rs/misc-cleanups (2020-09-06) 3 commits\n (merged to 'next' on 2020-09-09 at 4a19ea9672)\n + pack-bitmap-write: use hashwrite_be32() in write_hash_cache()\n + midx: use hashwrite_u8() in write_midx_header()\n + fast-import: use write_pack_header()\n\n Misc cleanups.\n\n Will merge to 'master'.\n\n\n* rs/parallel-read-cache-fix (2020-09-06) 1 commit\n (merged to 'next' on 2020-09-09 at 92953a75c4)\n + read-cache: fix mem-pool allocation for multi-threaded index loading\n\n A follow-up fix to a topic already in 'master'.\n\n Will merge to 'master'.\n\n\n* rs/refspec-leakfix (2020-09-06) 2 commits\n (merged to 'next' on 2020-09-09 at 10741e90a5)\n + refspec: add and use refspec_appendf()\n + push: release strbufs used for refspec formatting\n\n Leakfix.\n\n Will merge to 'master'.\n\n\n* so/log-tree-diff-cleanup (2020-09-06) 2 commits\n (merged to 'next' on 2020-09-09 at f8744b8e8a)\n + log_tree_diff: get rid of extra check for NULL\n + log_tree_diff: get rid of code duplication for first_parent_only\n\n Code cleanup.\n\n Will merge to 'master'.\n\n\n* hn/refs-trace-backend (2020-09-09) 1 commit\n - refs: add GIT_TRACE_REFS debugging mechanism\n\n Developer support.\n\n Will merge to 'next'.\n\n\n* jc/dist-tarball-tweak (2020-09-09) 1 commit\n - Makefile: allow extra tweaking of distribution tarball\n\n Allow maintainers to tweak $(TAR) invocations done while making\n distribution tarballs.\n\n Will merge to 'next'.\n\n\n* mt/config-fail-nongit-early (2020-09-09) 1 commit\n - config: complain about --worktree outside of a git repo\n\n Unlike \"git config --local\", \"git config --worktree\" did not fail\n early and cleanly when started outside a git repository.\n\n Will merge to 'next'.\n\n--------------------------------------------------\n[Stalled]\n\n* vv/send-email-with-less-secure-apps-access (2020-08-29) 1 commit\n - Documentation/git-send-email.txt: Mention less secure app access might need to enable.\n\n Doc update.\n\n Expecting a reroll.\n cf. \n cf. \n\n\n* jc/war-on-dashed-git (2020-08-27) 1 commit\n - git: catch an attempt to run \"git-foo\"\n\n The first step to remove on-disk binaries for built-in subcommands\n by soliciting objections.\n\n On hold for now.\n\n\n* dr/push-remoteref-fix (2020-04-23) 1 commit\n - remote.c: fix handling of %(push:remoteref)\n\n The \"%(push:remoteref)\" placeholder in the \"--format=\" argument of\n \"git format-patch\" (and friends) only showed what got explicitly\n configured, not what ref at the receiving end would be updated when\n \"git push\" was used, as it ignored the default behaviour (e.g. update\n the same ref as the source).\n\n Expecting a reroll.\n cf. <20200416152145.wp2zeibxmuyas6y6@feanor>\n cf. \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[Cooking]\n\n* tb/bloom-improvements (2020-09-09) 12 commits\n - builtin/commit-graph.c: introduce '--max-new-filters='\n - commit-graph: rename 'split_commit_graph_opts'\n - bloom: encode out-of-bounds filters as non-empty\n - bloom/diff: properly short-circuit on max_changes\n - bloom: use provided 'struct bloom_filter_settings'\n - bloom: split 'get_bloom_filter()' in two\n - commit-graph.c: store maximum changed paths\n - commit-graph: respect 'commitGraph.readChangedPaths'\n - t/helper/test-read-graph.c: prepare repo settings\n - commit-graph: pass a 'struct repository *' in more places\n - t4216: use an '&&'-chain\n - commit-graph: introduce 'get_bloom_filter_settings()'\n\n \"git commit-graph write\" learned to limit the number of bloom\n filters that are computed from scratch with the --max-new-filters\n option.\n\n\n* es/config-hooks (2020-09-09) 9 commits\n - run_commit_hook: take strvec instead of varargs\n - commit: use config-based hooks\n - hook: replace run-command.h:find_hook\n - hook: add 'run' subcommand\n - parse-options: parse into strvec\n - hook: add --porcelain to list command\n - hook: add list command\n - hook: scaffolding for git-hook subcommand\n - doc: propose hooks managed by the config\n\n The \"hooks defined in config\" topic.\n\n\n* ls/mergetool-meld-auto-merge (2020-09-09) 1 commit\n - Support auto-merge for meld to follow the vim-diff behavior\n\n The 'meld' backend of the \"git mergetool\" learned to give the\n underlying 'meld' the '--auto-merge' option, which would help\n reduce the amount of text that requires manual merging.\n\n Will merge to 'next'.\n\n\n* mf/submodule-summary-with-correct-repository (2020-06-24) 2 commits\n - submodule: use submodule repository when preparing summary\n - revision: use repository from rev_info when parsing commits\n\n \"git diff/show\" on a change that involves a submodule used to read\n the information on commits in the submodule from a wrong repository\n and gave a wrong information when the commit-graph is involved.\n\n Will merge to 'next'.\n cf. \n\n\n* pb/clang-json-compilation-database (2020-09-06) 1 commit\n (merged to 'next' on 2020-09-09 at 9f5ea136f1)\n + Makefile: add support for generating JSON compilation database\n\n Developer support.\n\n Will merge to 'master'.\n\n\n* mt/grep-sparse-checkout (2020-09-02) 8 commits\n - config: add setting to ignore sparsity patterns in some cmds\n - grep: honor sparse checkout patterns\n - config: correctly read worktree configs in submodules\n - t/helper/test-config: unify exit labels\n - t/helper/test-config: check argc before accessing argv\n - t/helper/test-config: be consistent with exit codes\n - t1308-config-set: avoid false positives when using test-config\n - doc: grep: unify info on configuration variables\n\n \"git grep\" has been tweaked to be limited to the sparse checkout\n paths.\n\n\n* ew/decline-core-abbrev (2020-09-01) 1 commit\n - core.abbrev disables abbreviations\n\n Allow the configuration to specify no abbreviation regardless of\n the hash algorithm.\n\n Expecting a reroll. The intent is very good.\n\n\n* mr/bisect-in-c-2 (2020-08-31) 13 commits\n - bisect--helper: retire `--bisect-autostart` subcommand\n - bisect--helper: retire `--write-terms` subcommand\n - bisect--helper: retire `--check-expected-revs` subcommand\n - bisect--helper: reimplement `bisect_state` & `bisect_head` shell functions in C\n - bisect--helper: retire `--next-all` subcommand\n - bisect--helper: retire `--bisect-clean-state` subcommand\n - bisect--helper: finish porting `bisect_start()` to C\n - bisect--helper: reimplement `bisect_next` and `bisect_auto_next` shell functions in C\n - bisect: call 'clear_commit_marks_all()' in 'bisect_next_all()'\n - bisect--helper: reimplement `bisect_autostart` shell function in C\n - bisect--helper: introduce new `write_in_file()` function\n - bisect--helper: use '-res' in 'cmd_bisect__helper' return\n - bisect--helper: BUG() in cmd_*() on invalid subcommand\n\n Rewrite of the \"git bisect\" script in C continues.\n\n At v7; getting close\n cf. \n\n\n* js/no-builtins-on-disk-option (2020-08-24) 3 commits\n - ci: stop linking built-ins to the dashed versions\n - install: optionally skip linking/copying the built-ins\n - msvc: copy the correct `.pdb` files in the Makefile target `install`\n\n The installation procedure learned to optionally omit \"git-foo\"\n executable files for each 'foo' built-in subcommand, which are only\n required by old timers that still rely on the age old promise that\n prepending \"git --exec-path\" output to PATH early in their script\n will keep the \"git-foo\" calls they wrote working.\n\n The old attempt to remove these executables from the disk failed in\n the 1.6 era; it may be worth attempting again, but I think it is\n worth to keep this topic separate from such a policy change to help\n it graduate early.\n\n Expecting a reroll to update log message for the last one.\n as it confused at least two reviewers.\n cf. \n cf. <20200903104537.GA27325@szeder.dev>\n\n\n* jt/threaded-index-pack (2020-09-08) 7 commits\n - index-pack: make quantum of work smaller\n - index-pack: make resolve_delta() assume base data\n - index-pack: calculate {ref,ofs}_{first,last} early\n - index-pack: remove redundant child field\n - index-pack: unify threaded and unthreaded code\n - index-pack: remove redundant parameter\n - Documentation: deltaBaseCacheLimit is per-thread\n\n \"git index-pack\" learned to resolve deltified objects with greater\n parallelism.\n\n Will merge to 'next'.\n\n\n* jk/refspecs-negative (2020-08-21) 1 commit\n - refspec: add support for negative refspecs\n\n \"negative refspecs\"\n\n\n* jx/proc-receive-hook (2020-08-27) 10 commits\n - doc: add documentation for the proc-receive hook\n - transport: parse report options for tracking refs\n - t5411: test updates of remote-tracking branches\n - receive-pack: new config receive.procReceiveRefs\n - doc: add document for capability report-status-v2\n - New capability \"report-status-v2\" for git-push\n - receive-pack: feed report options to post-receive\n - receive-pack: add new proc-receive hook\n - t5411: add basic test cases for proc-receive hook\n - transport: not report a non-head push as a branch\n\n \"git receive-pack\" that accepts requests by \"git push\" learned to\n outsource most of the ref updates to the new \"proc-receive\" hook.\n\n Will merge to 'next'.\n\n\n* ds/maintenance-part-2 (2020-09-06) 8 commits\n - maintenance: add incremental-repack auto condition\n - maintenance: auto-size incremental-repack batch\n - maintenance: add incremental-repack task\n - midx: use start_delayed_progress()\n - midx: enable core.multiPackIndex by default\n - maintenance: create auto condition for loose-objects\n - maintenance: add loose-objects task\n - maintenance: add prefetch task\n (this branch is used by ds/maintenance-part-3; uses ds/maintenance-part-1.)\n\n \"git maintenance\", an extended big brother of \"git gc\", continues\n to evolve.\n\n\n* ds/maintenance-part-1 (2020-09-06) 11 commits\n - maintenance: add trace2 regions for task execution\n - maintenance: add auto condition for commit-graph task\n - maintenance: use pointers to check --auto\n - maintenance: create maintenance..enabled config\n - maintenance: take a lock on the objects directory\n - maintenance: add --task option\n - maintenance: add commit-graph task\n - maintenance: initialize task array\n - maintenance: replace run_auto_gc()\n - maintenance: add --quiet option\n - maintenance: create basic maintenance runner\n (this branch is used by ds/maintenance-part-2 and ds/maintenance-part-3.)\n\n A \"git gc\"'s big brother has been introduced to take care of more\n repository maintenance tasks, not limited to the object database\n cleaning.\n\n Will merge to 'next'.\n\n--------------------------------------------------\n[Discarded]\n\n* jc/remove-pack-redundant (2020-08-25) 1 commit\n . pack-redundant: gauge the usage before proposing its removal\n\n The first step to remove \"git pack-redundant\" by soliciting\n objections.\n\n Stop--we had some activity as late as last year.\n"},{"id":"405307","messageId":"CAPig+cQnnukVoJTgsu1sGFWkAYv7V38-0s-CgYuMyizYHhSFQQ@mail.gmail.com","threadId":"54218","inReplyTo":"xmqq4ko6twc9.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2020-09-09T23:07:22Z","receivedAt":"2020-09-10T03:23:50Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Sep 9, 2020 at 6:33 PM Junio C Hamano wrote:\n> * es/format-patch-interdiff-cleanup (2020-09-08) 3 commits\n> - format-patch: use 'origin' as start of current-series-range when known\n> - diff-lib: tighten show_interdiff()'s interface\n> - diff: move show_interdiff() from its own file to diff-lib\n>\n> Code cleanup with a slight behaviour change when \"format-patch\n> --range-diff= origin..HEAD\" gives a single revision to\n> .\n\nPerhaps this could be a bit more precise by saying something like:\n\n Code cleanup and make \"format-patch --range-diff=\n ..HEAD\" not ignore when is a single\n revision.\n\n> * es/wt-add-detach (2020-09-06) 3 commits\n> - git-worktree.txt: discuss branch-based vs. throwaway worktrees\n> - worktree: teach `add` to recognize -d as shorthand for --detach\n> - git-checkout.txt: document -d short option for --detach\n>\n> \"git worktree add\" learns the \"--detach\" option to create a new\n> worktree without being on a branch.\n\nThis needs a tweak to avoid being incorrect. \"git worktree add\" has\nunderstood --detach from the start. This series only teaches it -d as\nan alias for --detach. So, perhaps:\n\n \"git worktree add\" learns \"-d\" as short for \"--detach\".\n"},{"id":"405312","messageId":"xmqqimcms06h.fsf@gitster.c.googlers.com","threadId":"54218","inReplyTo":"CAPig+cQnnukVoJTgsu1sGFWkAYv7V38-0s-CgYuMyizYHhSFQQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-10T04:52:38Z","receivedAt":"2020-09-10T04:52:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> On Wed, Sep 9, 2020 at 6:33 PM Junio C Hamano wrote:\n>> * es/format-patch-interdiff-cleanup (2020-09-08) 3 commits\n>> - format-patch: use 'origin' as start of current-series-range when known\n>> - diff-lib: tighten show_interdiff()'s interface\n>> - diff: move show_interdiff() from its own file to diff-lib\n>>\n>> Code cleanup with a slight behaviour change when \"format-patch\n>> --range-diff= origin..HEAD\" gives a single revision to\n>> .\n>\n> Perhaps this could be a bit more precise by saying something like:\n>\n> Code cleanup and make \"format-patch --range-diff=\n> ..HEAD\" not ignore when is a single\n> revision.\n\nSure. I didn't realize we can be more specific without spending too\nmany more bytes. Let me steal that description.\n\n> \"git worktree add\" learns \"-d\" as short for \"--detach\".\n\nThanks.\n"},{"id":"405561","messageId":"85ft7ivp1t.fsf@LAPTOP-ACER-ASPIRE-F5.i-did-not-set--mail-host-address--so-tickle-me","threadId":"54218","inReplyTo":"xmqq4ko6twc9.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2020-09-15T19:05:18Z","receivedAt":"2020-09-15T19:09:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Hello,\n\nJunio C Hamano writes:\n\n> * ss/submodule-summary-in-c (2020-08-12) 4 commits\n> (merged to 'next' on 2020-08-17 at 9bc352cb70)\n> + submodule: port submodule subcommand 'summary' from shell to C\n> + t7421: introduce a test script for verifying 'summary' output\n> + submodule: rename helper functions to avoid ambiguity\n> + submodule: remove extra line feeds between callback struct and macro\n> (this branch is used by ss/submodule-summary-in-c-fixes.)\n>\n> Yet another subcommand of \"git submodule\" is getting rewritten in C.\n>\n>\n> * ss/submodule-summary-in-c-fixes (2020-08-27) 3 commits\n> (merged to 'next' on 2020-09-02 at 7f959811b8)\n> + t7421: eliminate 'grep' check in t7421.4 for mingw compatibility\n> + submodule: fix style in function definition\n> + submodule: eliminate unused parameters from print_submodule_summary()\n> (this branch uses ss/submodule-summary-in-c.)\n>\n> Fixups to a topic in 'next'.\n\nThose are patches that are part of GSoC project of Shourya Shukla:\n'Convert submodule to builtin'.\n\n> * hv/ref-filter-misc (2020-08-28) 8 commits\n> (merged to 'next' on 2020-09-02 at 9a8bb84f20)\n> + ref-filter: add `sanitize` option for 'subject' atom\n> + pretty: refactor `format_sanitized_subject()`\n> + ref-filter: add `short` modifier to 'parent' atom\n> + ref-filter: add `short` modifier to 'tree' atom\n> + ref-filter: rename `objectname` related functions and fields\n> + ref-filter: modify error messages in `grab_objectname()`\n> + ref-filter: refactor `grab_objectname()`\n> + ref-filter: support different email formats\n>\n> The \"--format=\" option to the \"for-each-ref\" command and friends\n> learned a few more tricks, e.g. the \":short\" suffix that applies to\n> \"objectname\" now also can be used for \"parent\", \"tree\", etc.\n>\n\nThose are patches that are part of GSoC project of Hariom Verma:\n'Unify ref-filter formats with other --pretty formats'\n\nI'd like to point out that latest series of patches by Abhishek Kumar\nwhich are final part of 'Implement Generation Number v2' is at what I\nbelieve is next to final iteration:\n\n \"[PATCH v3 00/11] [GSoC] Implement Corrected Commit Date\"\n https://lore.kernel.org/git/pull.676.v3.git.1597509583.gitgitgadget@gmail.com/T/#u\n\nIt is waiting for the decision on *how to implement storing* new\ngeneration number in the commit-graph file: should we store corrected\ncommit date directly as 64 bit value, or should we store corrected\ncommit date offset as 32 bit value with overflow handling?\n\nSwitching from 64 bits to 32 bits halves the size of the GDAT\n(Generation DATa) chunk, but decreases the size of the commit-graph file\nby at most 7%. For large repository, like MS Windows with 3M commits in\n2019 it would mean decreasing the size of the commit-graph file by\n11.8 MiB (if I calculated it correctly).\n\nBecause corrected commit date offsets are not monotone, that is after\nvalue that doesn't fit in 32 bits (in parent) there can be one that does\n(in child). It is extremely unlikely that in real repositories there\nwould be that large corrections needed, but it can happen in theory, and\ntherfore we need some way to handle overflow if we choose this option.\nAnd of course we should test that overflow handling works correctly.\n\nSo there is tradeoff between complexity and commit-graph file size.\n\nBest,\n-- \nJakub Narębski\n"},{"id":"405562","messageId":"20200915193201.GA1741@nand.local","threadId":"54218","inReplyTo":"85ft7ivp1t.fsf@LAPTOP-ACER-ASPIRE-F5.i-did-not-set--mail-host-address--so-tickle-me","subject":"Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-09-15T19:32:01Z","receivedAt":"2020-09-15T19:32:49Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Hi Jakub,\n\nOn Tue, Sep 15, 2020 at 09:05:18PM +0200, Jakub Narębski wrote:\n> I'd like to point out that latest series of patches by Abhishek Kumar\n> which are final part of 'Implement Generation Number v2' is at what I\n> believe is next to final iteration:\n>\n> \"[PATCH v3 00/11] [GSoC] Implement Corrected Commit Date\"\n> https://lore.kernel.org/git/pull.676.v3.git.1597509583.gitgitgadget@gmail.com/T/#u\n>\n> It is waiting for the decision on *how to implement storing* new\n> generation number in the commit-graph file: should we store corrected\n> commit date directly as 64 bit value, or should we store corrected\n> commit date offset as 32 bit value with overflow handling?\n>\n> Switching from 64 bits to 32 bits halves the size of the GDAT\n> (Generation DATa) chunk, but decreases the size of the commit-graph file\n> by at most 7%. For large repository, like MS Windows with 3M commits in\n> 2019 it would mean decreasing the size of the commit-graph file by\n> 11.8 MiB (if I calculated it correctly).\n>\n> Because corrected commit date offsets are not monotone, that is after\n> value that doesn't fit in 32 bits (in parent) there can be one that does\n> (in child). It is extremely unlikely that in real repositories there\n> would be that large corrections needed, but it can happen in theory, and\n> therfore we need some way to handle overflow if we choose this option.\n> And of course we should test that overflow handling works correctly.\n>\n> So there is tradeoff between complexity and commit-graph file size.\n\nIf you think that not being able to fit into 32 bits is unlikely, then I\ndon't think it makes sense to store those same values inside of 64 bits,\neither.\n\nOf course, that means implementing overflow detection, but that's a\nsmall price to pay for shaving off extra data from the commit-graph\nfile.\n\n> Best,\n> --\n> Jakub Narębski\n\nThanks,\nTaylor\n"},{"id":"405568","messageId":"xmqqimcezqs5.fsf@gitster.c.googlers.com","threadId":"54218","inReplyTo":"85ft7ivp1t.fsf@LAPTOP-ACER-ASPIRE-F5.i-did-not-set--mail-host-address--so-tickle-me","subject":"Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-15T21:14:18Z","receivedAt":"2020-09-15T21:16:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"jnareb@gmail.com (Jakub Narębski) writes:\n\n> Those are patches that are part of GSoC project of Shourya Shukla:\n> 'Convert submodule to builtin'.\n> ...\n> Those are patches that are part of GSoC project of Hariom Verma:\n> 'Unify ref-filter formats with other --pretty formats'\n\nYes and yes. What is your intention for highlighting that these two\nare GSoC originated projects, by the way? \n\nThese entries in the What's cooking report will eventually be part\nof the Release Notes, it is tempting to mention it there for\npublicity of the GSoC program (and I happen to work for OSPO that\nruns the program).\n\nBut at the same time, it becomes part of the published history\n(i.e. commit log for the merge commits) and over there, I am not\nsure if we want to mention GSoC---who the changes came from and in\nwhat context is much less important than what the actual changes are\nwhile reading the history of the project, trying to understand the\ncurrent state of the code [*1*].\n\n> I'd like to point out that latest series of patches by Abhishek Kumar\n> which are final part of 'Implement Generation Number v2' is at what I\n> believe is next to final iteration:\n\nYup, I've been watching from the sideline and appreciate that you've\ngiven the author quite a lot of help to make the series into a good\nshape.\n\n> Because corrected commit date offsets are not monotone, that is after\n> value that doesn't fit in 32 bits (in parent) there can be one that does\n> (in child). It is extremely unlikely that in real repositories there\n> would be that large corrections needed, but it can happen in theory, and\n> therfore we need some way to handle overflow if we choose this option.\n> And of course we should test that overflow handling works correctly.\n\nMy gut feeling is that overflow handling needs there whether the\nfield is 32-bit or 64-bit.\n\nThanks.\n\n\n[Footnote]\n\n*1* Unless you want to have more cues to notice commits by less\n experienced contributors and want to focus more carefully while\n bisecting the history or something like that, that is.\n"},{"id":"405571","messageId":"CANQwDwc3-n4X16F1Xuf-y-yLeXoGRTeT5c=kVVFXH1E6P=ZEqA@mail.gmail.com","threadId":"54218","inReplyTo":"xmqqimcezqs5.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2020-09-15T21:25:16Z","receivedAt":"2020-09-15T21:27:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 15 Sep 2020 at 23:14, Junio C Hamano wrote:\n> jnareb@gmail.com (Jakub Narębski) writes:\n>\n> > Those are patches that are part of GSoC project of Shourya Shukla:\n> > 'Convert submodule to builtin'.\n> > ...\n> > Those are patches that are part of GSoC project of Hariom Verma:\n> > 'Unify ref-filter formats with other --pretty formats'\n>\n> Yes and yes. What is your intention for highlighting that these two\n> are GSoC originated projects, by the way?\n\nIt was to compare the final status (merged vs not merged) of all Git's\nGSoC 2020 projects... in a bit clumsy way, I admit.\n\n[...]\n> > Because corrected commit date offsets are not monotone, that is after\n> > value that doesn't fit in 32 bits (in parent) there can be one that does\n> > (in child). It is extremely unlikely that in real repositories there\n> > would be that large corrections needed, but it can happen in theory, and\n> > therefore we need some way to handle overflow if we choose this option.\n> > And of course we should test that overflow handling works correctly.\n>\n> My gut feeling is that overflow handling needs to be there whether the\n> field is 32-bit or 64-bit.\n\nNot if the size on-disk is the same as the size in memory:\ntimestamp_t is usually 64 bit (and even unsigned 64 bit epoch\nwould be enough - its range is over twenty times the present\nage of the universe per direction).\n\nBest,\n-- \nJakub Narębski\n"},{"id":"405574","messageId":"xmqqzh5qyar4.fsf@gitster.c.googlers.com","threadId":"54218","inReplyTo":"CANQwDwc3-n4X16F1Xuf-y-yLeXoGRTeT5c=kVVFXH1E6P=ZEqA@mail.gmail.com","subject":"Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-15T21:45:51Z","receivedAt":"2020-09-15T21:47:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narębski writes:\n\n\n>> My gut feeling is that overflow handling needs to be there whether the\n>> field is 32-bit or 64-bit.\n>\n> Not if the size on-disk is the same as the size in memory:\n> timestamp_t is usually 64 bit (and even unsigned 64 bit epoch\n> would be enough - its range is over twenty times the present\n> age of the universe per direction).\n\nYes, and \"corrected commit dates\" is about accommodating commits\nwith absurd out-of-sync timestamp mixed in a history with commits\nwith correct timestamp, right? What happens if the absurd timestamp\nis near the limit of the range? You do not have to live through the\nend of the universe---you only have to create a commit object that\nrecords such a timestamp, no?\n\n"},{"id":"405575","messageId":"20200915214802.GB1741@nand.local","threadId":"54218","inReplyTo":"xmqqzh5qyar4.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-09-15T21:48:02Z","receivedAt":"2020-09-15T21:49:01Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Sep 15, 2020 at 02:45:51PM -0700, Junio C Hamano wrote:\n> Jakub Narębski writes:\n>\n>\n> >> My gut feeling is that overflow handling needs to be there whether the\n> >> field is 32-bit or 64-bit.\n> >\n> > Not if the size on-disk is the same as the size in memory:\n> > timestamp_t is usually 64 bit (and even unsigned 64 bit epoch\n> > would be enough - its range is over twenty times the present\n> > age of the universe per direction).\n>\n> Yes, and \"corrected commit dates\" is about accommodating commits\n> with absurd out-of-sync timestamp mixed in a history with commits\n> with correct timestamp, right? What happens if the absurd timestamp\n> is near the limit of the range? You do not have to live through the\n> end of the universe---you only have to create a commit object that\n> records such a timestamp, no?\n\nI completely agree with Junio's sentiment here. The overflow handling\nneeds to exist no matter what, but let's remember what's common and what\nisn't.\n\nSince it's not common to be towards the end of even just the 32-bit\nrange, let's \"optimize\" for that and store the fields as 32 bits wide.\n\n\nThanks,\nTaylor\n"},{"id":"405578","messageId":"CANQwDwdgjV8ZTHKdUjEn5TKTXvTcODTXnbLEinWSQDYpZzfAvA@mail.gmail.com","threadId":"54218","inReplyTo":"xmqqzh5qyar4.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2020-09-15T22:02:34Z","receivedAt":"2020-09-15T22:03:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 15 Sep 2020 at 23:45, Junio C Hamano wrote:\n>\n> Jakub Narębski writes:\n>\n>\n> >> My gut feeling is that overflow handling needs to be there whether the\n> >> field is 32-bit or 64-bit.\n> >\n> > Not if the size on-disk is the same as the size in memory:\n> > timestamp_t is usually 64 bit (and even unsigned 64 bit epoch\n> > would be enough - its range is over twenty times the present\n> > age of the universe per direction).\n>\n> Yes, and \"corrected commit dates\" is about accommodating commits\n> with absurd out-of-sync timestamp mixed in a history with commits\n> with correct timestamp, right? What happens if the absurd timestamp\n> is near the limit of the range? You do not have to live through the\n> end of the universe---you only have to create a commit object that\n> records such a timestamp, no?\n\nWell, as Git stores dates using timestamp_t type, it wouldn't\nbe able to handle such commit dates anyway. Also, commit-graph\nformat has only 34 bits reserved for storing commit dates anyway\n(32 + 2 bits, with 30 bits of the other byte used for topological\nlevels aka generation number v1).\n\nAs parse_timestamp is strtoumax, having textual representation\nof timestamp not fit in 64 bits results in a range error (errno,\nwhich we do not check, is set to ERANGE) and UINTMAX_MAX\nis returned.\n\nBest,\n-- \nJakub Narębski\n"},{"id":"405581","messageId":"xmqqr1r2y8lr.fsf@gitster.c.googlers.com","threadId":"54218","inReplyTo":"20200915214802.GB1741@nand.local","subject":"Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-15T22:32:16Z","receivedAt":"2020-09-15T22:32:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> I completely agree with Junio's sentiment here. The overflow handling\n> needs to exist no matter what, but let's remember what's common and what\n> isn't.\n>\n> Since it's not common to be towards the end of even just the 32-bit\n> range, let's \"optimize\" for that and store the fields as 32 bits wide.\n\nThanks. I realize I wasn't clear but that is what I meant. If we\nneed to deal with overflowing situation sensibly anyway, there may\nnot be much advantage in using 64-bit until year 2038.\n"},{"id":"405584","messageId":"CAPig+cQenifmJ5TW1Sh0zimmbAGDXvfkJRTVDg0nyRJ1vfU+wQ@mail.gmail.com","threadId":"54218","inReplyTo":"xmqqimcms06h.fsf@gitster.c.googlers.com","subject":"Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2020-09-15T22:48:32Z","receivedAt":"2020-09-15T22:49:08Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, Sep 10, 2020 at 12:52 AM Junio C Hamano wrote:\n> Eric Sunshine writes:\n> > \"git worktree add\" learns \"-d\" as short for \"--detach\".\n>\n> Thanks.\n\nSince this thread is active again, I guess I'll nudge this a bit. The\nes/wt-add-detach topic still seems to need the above tweak to prevent\nit from being inaccurate[1]. (At least I don't see the updated merge\nmessage in 'seen' yet.) Thanks.\n\n[1]: https://lore.kernel.org/git/CAPig+cQnnukVoJTgsu1sGFWkAYv7V38-0s-CgYuMyizYHhSFQQ@mail.gmail.com/\n"},{"id":"405586","messageId":"xmqqmu1qy7kh.fsf@gitster.c.googlers.com","threadId":"54218","inReplyTo":"CAPig+cQenifmJ5TW1Sh0zimmbAGDXvfkJRTVDg0nyRJ1vfU+wQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-09-15T22:54:38Z","receivedAt":"2020-09-15T22:55:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> On Thu, Sep 10, 2020 at 12:52 AM Junio C Hamano wrote:\n>> Eric Sunshine writes:\n>> > \"git worktree add\" learns \"-d\" as short for \"--detach\".\n>>\n>> Thanks.\n>\n> Since this thread is active again, I guess I'll nudge this a bit. The\n> es/wt-add-detach topic still seems to need the above tweak to prevent\n> it from being inaccurate[1]. (At least I don't see the updated merge\n> message in 'seen' yet.) Thanks.\n\nThanks. https://github.com/git/git/commit/698501fba3\n\n"}]}