{"thread":{"id":"42635","subject":"What's cooking in git.git (Jun 2016, #05; Thu, 16)","startedAt":"2016-06-17T03:20:35Z","lastAt":"2016-07-14T18:17:52Z","messageCount":31,"participants":["Junio C Hamano","Pranit Bauva","Vasco Almeida","Lars Schneider","Michael Haggerty","Torsten Bögershausen","Joey Hess"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"289420","messageId":"xmqqk2ho33ig.fsf@gitster.mtv.corp.google.com","threadId":"42635","inReplyTo":null,"subject":"What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-17T03:20:23Z","receivedAt":"2016-06-17T03:20:35Z","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\nLet's start a new cycle by rewinding the tip of 'next' soonish.  I\nexpect I'd eject a few premature topics out of 'next' while doing\nso.  There are many topics that need input from the list (look for\n'?' in this document) to decide either to drop them or to move them\nforward.\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[New Topics]\n\n* ap/git-svn-propset-doc (2016-06-15) 1 commit\n - git-svn: document the 'git svn propset' command\n\n \"git svn propset\" subcommand that was added in 2.3 days is\n documented now.\n\n Will merge to 'next'.\n\n\n* jk/add-i-diff-compact-heuristics (2016-06-16) 1 commit\n - add--interactive: respect diff.compactionHeuristic\n\n \"git add -i/-p\" learned to honor diff.compactionHeuristic\n experimental knob, so that the user can work on the same hunk split\n as \"git diff\" output.\n\n Will merge to 'next'.\n\n\n* jk/big-and-old-archive-tar (2016-06-16) 2 commits\n - archive-tar: write extended headers for far-future mtime\n - archive-tar: write extended headers for file sizes >= 8GB\n\n \"git archive\" learned to handle files that are larger than 8GB and\n commits far in the future than expressible by the traditional US-TAR\n format.\n\n Will merge to 'next'.\n\n\n* jk/gpg-interface-cleanup (2016-06-16) 7 commits\n - gpg-interface: check gpg signature creation status\n - sign_buffer: use pipe_command\n - verify_signed_buffer: use pipe_command\n - run-command: add pipe_command helper\n - verify_signed_buffer: use tempfile object\n - verify_signed_buffer: drop pbuf variable\n - gpg-interface: use child_process.args\n\n A new run-command API function pipe_command() is introduced to\n sanely feed data to the standard input while capturing data from\n the standard output and the standard error of an external process,\n which is cumbersome to hand-roll correctly without deadlocking.\n\n The codepath to sign data in a prepared buffer with GPG has been\n updated to use this API to read from the status-fd to check for\n errors (instead of relying on GPG's exit status).\n\n Will merge to 'next'.\n\n\n* lf/sideband-returns-void (2016-06-16) 2 commits\n - upload-pack.c: make send_client_data() return void\n - sideband.c: make send_sideband() return void\n\n A small internal API cleanup.\n\n Will merge to 'next'.\n\n\n* nd/graph-width-padded (2016-06-16) 2 commits\n - pretty.c: support <direction>|(<negative number>) forms\n - pretty: pass graph width to pretty formatting for use in '%>|(N)'\n\n \"log --graph --format=\" learned that \"%>|(N)\" specifies the width\n relative to the terminal's left edge, not relative to the area to\n draw text that is to the right of the ancestry-graph section.  It\n also now accepts negative N that means the column limit is relative\n to the right border.\n\n Will merge to 'next'.\n\n\n* dn/gpg-doc (2016-06-16) 1 commit\n - Documentation: GPG capitalization\n\n The documentation tries to consistently spell \"GPG\"; when\n referring to the specific program name, \"gpg\" is used.\n\n Will merge to 'next'.\n\n\n* jk/bisect-show-tree (2016-06-16) 1 commit\n - bisect: always call setup_revisions after init_revisions\n\n \"git bisect\" makes an internal call to \"git diff-tree\" when\n bisection finds the culprit, but this call did not initialize the\n data structure to pass to the diff-tree API correctly.\n\n Will merge to 'next'.\n\n--------------------------------------------------\n[Stalled]\n\n* mj/log-show-signature-conf (2016-06-06) 2 commits\n - log: \"--no-show-signature\" commmand-line option\n - log: add \"log.showsignature\" configuration variable\n\n \"git log\" learns log.showSignature configuration variable, and a\n command line option \"--no-show-signature\" to countermand it.\n\n The order of the commits in the topic need to be reversed.\n Expecting a reroll.\n\n\n* sb/bisect (2016-04-15) 22 commits\n - SQUASH???\n - bisect: get back halfway shortcut\n - bisect: compute best bisection in compute_relevant_weights()\n - bisect: use a bottom-up traversal to find relevant weights\n - bisect: prepare for different algorithms based on find_all\n - bisect: rename count_distance() to compute_weight()\n - bisect: make total number of commits global\n - bisect: introduce distance_direction()\n - bisect: extract get_distance() function from code duplication\n - bisect: use commit instead of commit list as arguments when appropriate\n - bisect: replace clear_distance() by unique markers\n - bisect: use struct node_data array instead of int array\n - bisect: get rid of recursion in count_distance()\n - bisect: make algorithm behavior independent of DEBUG_BISECT\n - bisect: make bisect compile if DEBUG_BISECT is set\n - bisect: plug the biggest memory leak\n - bisect: add test for the bisect algorithm\n - t6030: generalize test to not rely on current implementation\n - t: use test_cmp_rev() where appropriate\n - t/test-lib-functions.sh: generalize test_cmp_rev\n - bisect: allow 'bisect run' if no good commit is known\n - bisect: write about `bisect next` in documentation\n\n The internal algorithm used in \"git bisect\" to find the next commit\n to check has been optimized greatly.\n\n Expecting a reroll.\n ($gmane/291163)\n\n\n* sg/completion-updates (2016-02-28) 21 commits\n . completion: cache the path to the repository\n . completion: extract repository discovery from __gitdir()\n . completion: don't guard git executions with __gitdir()\n . completion: consolidate silencing errors from git commands\n . completion: don't use __gitdir() for git commands\n . completion: respect 'git -C <path>'\n . completion: fix completion after 'git -C <path>'\n . completion: don't offer commands when 'git --opt' needs an argument\n . rev-parse: add '--absolute-git-dir' option\n . completion: list short refs from a remote given as a URL\n . completion: don't list 'HEAD' when trying refs completion outside of a repo\n . completion: list refs from remote when remote's name matches a directory\n . completion: respect 'git --git-dir=<path>' when listing remote refs\n . completion: fix most spots not respecting 'git --git-dir=<path>'\n . completion: ensure that the repository path given on the command line exists\n . completion tests: add tests for the __git_refs() helper function\n . completion tests: check __gitdir()'s output in the error cases\n . completion tests: consolidate getting path of current working directory\n . completion tests: make the $cur variable local to the test helper functions\n . completion tests: don't add test cruft to the test repository\n . completion: improve __git_refs()'s in-code documentation\n\n Will be rerolled.\n ($gmane/287839)\n\n\n* nd/icase (2016-02-15) 12 commits\n - grep.c: reuse \"icase\" variable\n - diffcore-pickaxe: support case insensitive match on non-ascii\n - diffcore-pickaxe: \"share\" regex error handling code\n - grep/pcre: support utf-8\n - gettext: add is_utf8_locale()\n - grep/pcre: prepare locale-dependent tables for icase matching\n - grep/icase: avoid kwsset when -F is specified\n - grep/icase: avoid kwsset on literal non-ascii strings\n - test-regex: expose full regcomp() to the command line\n - test-regex: isolate the bug test code\n - grep: break down an \"if\" stmt in preparation for next changes\n - grep: allow -F -i combination\n\n \"git grep -i\" has been taught to fold case in non-ascii locales.\n\n This really needs review.  What it attempts to achieve is\n worthwhile, I would think ($gmane/286137).\n\n\n* ec/annotate-deleted (2015-11-20) 1 commit\n - annotate: skip checking working tree if a revision is provided\n\n Usability fix for annotate-specific \"<file> <rev>\" syntax with deleted\n files.\n\n Waiting for review.\n\n\n* dg/subtree-rebase-test (2016-01-19) 1 commit\n - contrib/subtree: Add a test for subtree rebase that loses commits\n\n Reviewed up to v5.\n Will be rerolled.\n ($gmane/284426)\n\n\n* dk/gc-more-wo-pack (2016-01-13) 4 commits\n - gc: clean garbage .bitmap files from pack dir\n - t5304: ensure non-garbage files are not deleted\n - t5304: test .bitmap garbage files\n - prepare_packed_git(): find more garbage\n\n Follow-on to dk/gc-idx-wo-pack topic, to clean up stale\n .bitmap and .keep files.\n\n Waiting for a reroll.\n ($gmane/284368).\n\n\n* jc/diff-b-m (2015-02-23) 5 commits\n . WIPWIP\n . WIP: diff-b-m\n - diffcore-rename: allow easier debugging\n - diffcore-rename.c: add locate_rename_src()\n - diffcore-break: allow debugging\n\n \"git diff -B -M\" produced incorrect patch when the postimage of a\n completely rewritten file is similar to the preimage of a removed\n file; such a resulting file must not be expressed as a rename from\n other place.\n\n The fix in this patch is broken, unfortunately.\n Will discard.\n\n--------------------------------------------------\n[Cooking]\n\n* lv/status-say-working-tree-not-directory (2016-06-09) 1 commit\n - Use \"working tree\" instead of \"working directory\" for git status\n\n \"git status\" used to say \"working directory\" when it meant \"working\n tree\".\n\n Will merge to 'next'.\n\n\n* jk/parseopt-string-list (2016-06-13) 3 commits\n - blame,shortlog: don't make local option variables static\n - interpret-trailers: don't duplicate option strings\n - parse_opt_string_list: stop allocating new strings\n (this branch is used by jk/string-list-static-init.)\n\n The command line argument parsing that uses OPT_STRING_LIST() often\n made a copy of the argv[] element, which was unnecessary.\n\n Will merge to 'next'.\n\n\n* jk/repack-keep-unreachable (2016-06-14) 3 commits\n - repack: extend --keep-unreachable to loose objects\n - repack: add --keep-unreachable option\n - repack: document --unpack-unreachable option\n\n \"git repack\" learned the \"--keep-unreachable\" option, which sends\n loose unreachable objects to a pack instead of leaving them loose.\n This helps heuristics based on the number of loose objects\n (e.g. \"gc --auto\").\n\n Will merge to 'next'.\n\n\n* lf/recv-sideband-cleanup (2016-06-13) 1 commit\n - sideband.c: refactor recv_sideband()\n\n Code simplification.  It however loses the atomicity of the output\n 9ac13ec9 (atomic write for sideband remote messages, 2006-10-11)\n tried to add to an once-much-simpler codebase.\n\n Expecting a reroll.\n\n\n* nd/test-lib-httpd-show-error-log-in-verbose (2016-06-13) 1 commit\n - lib-httpd.sh: print error.log on error\n\n Debugging aid.\n\n Will merge to 'next'.\n\n\n* pc/occurred (2016-06-10) 2 commits\n - config.c: fix misspelt \"occurred\" in an error message\n - refs.h: fix misspelt \"occurred\" in a comment\n\n Will merge to 'next'.\n\n\n* sb/submodule-clone-retry (2016-06-13) 2 commits\n - submodule update: continue when a clone fails\n - submodule--helper: initial clone learns retry logic\n (this branch uses sb/submodule-recommend-shallowness.)\n\n \"git submodule update\" that drives many \"git clone\" could\n eventually hit flaky servers/network conditions on one of the\n submodules; the command learned to retry the attempt.\n\n Will merge to 'next'.\n\n\n* jc/blame-reverse (2016-06-14) 2 commits\n - blame: dwim \"blame --reverse OLD\" as \"blame --reverse OLD..\"\n - blame: improve diagnosis for \"--reverse NEW\"\n\n It is a common mistake to say \"git blame --reverse OLD path\",\n expecting that the command line is dwimmed as if asking how lines\n in path in an old revision OLD have survived up to the current\n commit.\n\n Any supporters?  Otherwise will drop.\n\n\n* jc/deref-tag (2016-06-14) 1 commit\n - blame, line-log: do not loop around deref_tag()\n\n Code clean-up.\n\n Will merge to 'next'.\n\n\n* jk/fetch-prune-doc (2016-06-14) 1 commit\n - fetch: document that pruning happens before fetching\n\n Will merge to 'next'.\n\n\n* km/fetch-do-not-free-remote-name (2016-06-14) 1 commit\n - builtin/fetch.c: don't free remote->name after fetch\n\n Will merge to 'next'.\n\n\n* nb/gnome-keyring-build (2016-06-14) 1 commit\n - gnome-keyring: Don't hard-code pkg-config executable\n\n Build improvements for gnome-keyring (in contrib/)\n\n Will merge to 'next'.\n\n\n* pb/strbuf-read-file-doc (2016-06-14) 1 commit\n - strbuf: describe the return value of strbuf_read_file\n\n Will merge to 'next'.\n\n\n* nd/shallow-deepen (2016-06-13) 27 commits\n - fetch, upload-pack: --deepen=N extends shallow boundary by N commits\n - upload-pack: add get_reachable_list()\n - upload-pack: split check_unreachable() in two, prep for get_reachable_list()\n - t5500, t5539: tests for shallow depth excluding a ref\n - clone: define shallow clone boundary with --shallow-exclude\n - fetch: define shallow boundary with --shallow-exclude\n - upload-pack: support define shallow boundary by excluding revisions\n - refs: add expand_ref()\n - t5500, t5539: tests for shallow depth since a specific date\n - clone: define shallow clone boundary based on time with --shallow-since\n - fetch: define shallow boundary with --shallow-since\n - upload-pack: add deepen-since to cut shallow repos based on time\n - shallow.c: implement a generic shallow boundary finder based on rev-list\n - fetch-pack: use a separate flag for fetch in deepening mode\n - fetch-pack.c: mark strings for translating\n - fetch-pack: use a common function for verbose printing\n - fetch-pack: use skip_prefix() instead of starts_with()\n - upload-pack: move rev-list code out of check_non_tip()\n - upload-pack: make check_non_tip() clean things up on error\n - upload-pack: tighten number parsing at \"deepen\" lines\n - upload-pack: use skip_prefix() instead of starts_with()\n - upload-pack: move \"unshallow\" sending code out of deepen()\n - upload-pack: remove unused variable \"backup\"\n - upload-pack: move \"shallow\" sending code out of deepen()\n - upload-pack: move shallow deepen code out of receive_needs()\n - transport-helper.c: refactor set_helper_option()\n - remote-curl.c: convert fetch_git() to use argv_array\n\n The existing \"git fetch --depth=<n>\" option was hard to use\n correctly when making the history of an existing shallow clone\n deeper.  A new option, \"--deepen=<n>\", has been added to make this\n easier to use.  \"git clone\" also learned \"--shallow-since=<date>\"\n and \"--shallow-exclude=<tag>\" options to make it easier to specify\n \"I am interested only in the recent N months worth of history\" and\n \"Give me only the history since that version\".\n\n Rerolled.\n Needs review.  What this topic attempts to achieve is worthwhile, I\n would think.\n\n\n* jk/avoid-unbounded-alloca (2016-06-07) 1 commit\n - tree-diff: avoid alloca for large allocations\n\n Will merge to 'next'.\n\n\n* jk/send-pack-stdio (2016-06-10) 2 commits\n - write_or_die: remove the unused write_or_whine() function\n - send-pack: use buffered I/O to talk to pack-objects\n\n Code clean-up.\n\n Will merge to 'next'.\n\n\n* pb/commit-editmsg-path (2016-06-09) 1 commit\n - builtin/commit.c: memoize git-path for COMMIT_EDITMSG\n\n Code clean-up.\n\n Will merge to 'next'.\n\n\n* wd/userdiff-css (2016-06-03) 1 commit\n  (merged to 'next' on 2016-06-06 at 536102f)\n + userdiff: add built-in pattern for CSS\n\n Update the funcname definition to support css files.\n\n Will merge to 'master'.\n\n\n* jc/attr-more (2016-06-09) 8 commits\n - attr.c: outline the future plans by heavily commenting\n - attr.c: always pass check[] to collect_some_attrs()\n - attr.c: introduce empty_attr_check_elems()\n - attr.c: correct ugly hack for git_all_attrs()\n - attr.c: rename a local variable check\n - fixup! d5ad6c13\n - attr.c: pass struct git_attr_check down the callchain\n - attr.c: add push_stack() helper\n (this branch uses jc/attr; is tangled with sb/pathspec-label and sb/submodule-default-paths.)\n\n The beginning of long and tortuous journey to clean-up attribute\n subsystem implementation.\n\n Needs to be redone.\n\n\n* jk/rev-list-count-with-bitmap (2016-06-03) 2 commits\n  (merged to 'next' on 2016-06-06 at dd9b30f)\n + rev-list: disable bitmaps when \"-n\" is used with listing objects\n + rev-list: \"adjust\" results of \"--count --use-bitmap-index -n\"\n\n \"git rev-list --count\" whose walk-length is limited with \"-n\"\n option did not work well with the counting optimized to look at the\n bitmap index.\n\n Will merge to 'master'.\n\n\n* mh/ref-iterators (2016-06-03) 13 commits\n  (merged to 'next' on 2016-06-06 at c8e79dc)\n + for_each_reflog(): reimplement using iterators\n + dir_iterator: new API for iterating over a directory tree\n + for_each_reflog(): don't abort for bad references\n + do_for_each_ref(): reimplement using reference iteration\n + refs: introduce an iterator interface\n + ref_resolves_to_object(): new function\n + entry_resolves_to_object(): rename function from ref_resolves_to_object()\n + get_ref_cache(): only create an instance if there is a submodule\n + remote rm: handle symbolic refs correctly\n + delete_refs(): add a flags argument\n + refs: use name \"prefix\" consistently\n + do_for_each_ref(): move docstring to the header file\n + refs: remove unnecessary \"extern\" keywords\n (this branch is used by mh/ref-store; uses mh/split-under-lock; is tangled with mh/update-ref-errors.)\n\n The API to iterate over all the refs (i.e. for_each_ref(), etc.)\n has been revamped.\n\n Will merge to 'master'.\n\n\n* ew/mboxrd-format-am (2016-06-06) 3 commits\n - am: support --patch-format=mboxrd\n - mailsplit: support unescaping mboxrd messages\n - pretty: support \"mboxrd\" output format\n\n Teach format-patch and mailsplit (hence \"am\") how a line that\n happens to begin with \"From \" in the e-mail message is quoted with\n \">\", so that these lines can be restored to their original shape.\n\n Will merge to 'next'.\n\n\n* lf/receive-pack-auto-gc-to-client (2016-06-06) 1 commit\n - receive-pack: send auto-gc output over sideband 2\n\n Allow messages that are generated by auto gc during \"git push\" on\n the receiving end to be explicitly passed back to the sending end\n over sideband, so that they are shown with \"remote: \" prefix to\n avoid confusing the users.\n\n Will merge to 'next'.\n\n\n* mg/cherry-pick-multi-on-unborn (2016-06-06) 1 commit\n - cherry-pick: allow to pick to unborn branches\n\n \"git cherry-pick A\" worked on an unborn branch, but \"git\n cherry-pick A..B\" didn't.\n\n Will merge to 'next'.\n\n\n* sg/reflog-past-root (2016-06-06) 1 commit\n - reflog: continue walking the reflog past root commits\n\n \"git reflog\" stopped upon seeing an entry that denotes a branch\n creation event (aka \"unborn\"), which made it appear as if the\n reflog was truncated.\n\n Will merge to 'next'.\n\n\n* tb/complete-status (2016-06-10) 3 commits\n - completion: add git status\n - completion: add __git_get_option_value helper\n - completion: factor out untracked file modes into a variable\n\n The completion script (in contrib/) learned to complete \"git\n status\" options.\n\n Any further comments?  Otherwise will merge to 'next'.\n\n\n* tr/doc-tt (2016-06-08) 4 commits\n - doc: change configuration variables format\n - doc: more consistency in environment variables format\n - doc: change environment variables format\n - doc: clearer rule about formatting literals\n\n The documentation set has been updated so that literal commands,\n configuration variables and environment variables are consistently\n typeset in fixed-width font and bold in manpages.\n\n Will merge to 'next'.\n\n\n* vs/prompt-avoid-unset-variable (2016-06-06) 1 commit\n - git-prompt.sh: Don't error on null ${ZSH,BASH}_VERSION, $short_sha\n\n The git-prompt scriptlet (in contrib/) was not friendly with those\n who uses \"set -u\", which has been fixed.\n\n Will merge to 'next'.\n\n\n* rj/compat-regex-size-max-fix (2016-06-06) 1 commit\n - regex: fix a SIZE_MAX macro redefinition warning\n\n A compilation fix.\n\n Will merge to 'next'.\n\n\n* et/add-chmod-x (2016-06-07) 1 commit\n - add: add --chmod=+x / --chmod=-x options\n\n \"git update-index --add --chmod=+x file\" may be usable as an escape\n hatch, but not a friendly thing to force for people who do need to\n use it regularly.  \"git add --chmod=+x file\" can be used instead.\n\n Will merge to 'next'.\n\n\n* mh/connect (2016-06-06) 10 commits\n - connect: [host:port] is legacy for ssh\n - connect: move ssh command line preparation to a separate function\n - connect: actively reject git:// urls with a user part\n - connect: change the --diag-url output to separate user and host\n - connect: make parse_connect_url() return the user part of the url as a separate value\n - connect: group CONNECT_DIAG_URL handling code\n - connect: make parse_connect_url() return separated host and port\n - connect: re-derive a host:port string from the separate host and port variables\n - connect: call get_host_and_port() earlier\n - connect: document why we sometimes call get_port after get_host_and_port\n\n Rewrite Git-URL parsing routine (hopefully) without changing any\n behaviour.\n\n Will merge to 'next'???\n\n\n* aq/upload-pack-use-parse-options (2016-05-31) 1 commit\n  (merged to 'next' on 2016-06-06 at 505f1ee)\n + upload-pack.c: use parse-options API\n\n \"git upload-pack\" command has been updated to use the parse-options\n API.\n\n Will merge to 'master'.\n\n\n* jc/clear-pathspec (2016-06-02) 1 commit\n  (merged to 'next' on 2016-06-06 at 9e7e291)\n + pathspec: rename free_pathspec() to clear_pathspec()\n\n We usually call a function that clears the contents a data\n structure X without freeing the structure itself clear_X(), and\n call a function that does clear_X() and also frees it free_X().\n free_pathspec() function has been renamed to clear_pathspec()\n to avoid confusion.\n\n Will merge to 'master'.\n\n\n* sb/submodule-recommend-shallowness (2016-05-27) 2 commits\n  (merged to 'next' on 2016-05-31 at 1ee161c)\n + submodule update: learn `--[no-]recommend-shallow` option\n + submodule-config: keep shallow recommendation around\n (this branch is used by sb/submodule-clone-retry.)\n\n An upstream project can make a recommendation to make only a\n shallow clone for some submodules in the .gitmodules file it ship.\n\n Will merge to 'master'.\n\n\n* tb/convert-peek-in-index (2016-06-07) 3 commits\n - correct ce_compare_data() in a middle of a merge\n - read-cache: factor out get_sha1_from_index() helper\n - convert: unify the \"auto\" handling of CRLF\n\n Needs review.\n\n\n* va/i18n-even-more (2016-06-07) 38 commits\n - i18n: branch: mark comment when editing branch description for translation\n - i18n: unmark die messages for translation\n - i18n: submodule: escape shell variables inside eval_gettext\n - i18n: submodule: join strings marked for translation\n - i18n: init-db: join message pieces\n - i18n: remote: allow translations to reorder message\n - i18n: remote: mark URL fallback text for translation\n - i18n: standardise messages\n - i18n: sequencer: add period to error message\n - i18n: merge: change command option help to lowercase\n - i18n: merge: mark messages for translation\n - i18n: notes: mark options for translation\n - i18n: notes: mark strings for translation\n - i18n: transport-helper.c: change N_() call to _()\n - i18n: bisect: mark strings for translation\n - t5523: use test_i18ngrep for negation\n - t4153: fix negated test_i18ngrep call\n - t9003: become resilient to GETTEXT_POISON\n - tests: unpack-trees: update to use test_i18n* functions\n - tests: use test_i18n* functions to suppress false positives\n - i18n: setup: mark strings for translation\n - i18n: rebase-interactive: mark comments of squash for translation\n - i18n: rebase-interactive: mark here-doc strings for translation\n - i18n: rebase-interactive: mark strings for translation\n - i18n: git-sh-setup.sh: mark strings for translation\n - t6030: update to use test_i18ncmp\n - i18n: bisect: simplify error message for i18n\n - i18n: rebase: mark placeholder for translation\n - i18n: rebase: fix marked string to use eval_gettext variant\n - merge-octupus: use die shell function from git-sh-setup.sh\n - i18n: merge-octopus: mark messages for translation\n - i18n: sequencer: mark string for translation\n - i18n: sequencer: mark entire sentences for translation\n - i18n: transport: mark strings for translation\n - i18n: advice: internationalize message for conflicts\n - i18n: advice: mark string about detached head for translation\n - i18n: builtin/remote.c: fix mark for translation\n - Merge branch 'jc/t2300-setup' into HEAD\n\n More markings of messages for i18n, with updates to various tests\n to pass GETTEXT_POISON tests.\n\n One patch from the original submission dropped due to conflicts\n with other topics in flight.\n\n Will merge to 'next'.\n\n\n* jg/dash-is-last-branch-in-worktree-add (2016-05-31) 1 commit\n  (merged to 'next' on 2016-06-02 at 3959ef6)\n + worktree: allow \"-\" short-hand for @{-1} in add command\n\n \"git worktree add\" learned that '-' can be used as a short-hand for\n \"@{-1}\", the previous branch.\n\n Will merge to 'master'.\n\n\n* dk/blame-move-no-reason-for-1-line-context (2016-05-29) 1 commit\n - blame: require 0 context lines while finding moved lines with -M\n\n \"git blame -M\" missed a single line that was moved within the file.\n\n We may want to squash a test or two to this commit.  Volunteers?\n\n\n* nd/worktree-lock (2016-06-13) 6 commits\n - worktree.c: find_worktree() search by path suffix\n - worktree: add \"unlock\" command\n - worktree: add \"lock\" command\n - worktree.c: add is_worktree_locked()\n - worktree.c: add is_main_worktree()\n - worktree.c: add find_worktree()\n (this branch uses nd/worktree-cleanup-post-head-protection.)\n\n \"git worktree prune\" protected worktrees that are marked as\n \"locked\" by creating a file in a known location.  \"git worktree\"\n command learned a dedicated command pair to create and remoev such\n a file, so that the users do not have to do this with editor.\n\n Is everybody happy with this version?\n If so, will merge to 'next'.\n\n\n* et/pretty-format-c-auto (2016-05-27) 1 commit\n  (merged to 'next' on 2016-05-31 at 1e9c920)\n + format_commit_message: honor `color=auto` for `%C(auto)`\n\n %C(auto) in a custom format string that commands in `git log`\n family takes unconditionally turned the color on, ignoring\n --no-color or --color=auto with output not connected to a tty;\n this was corrected to make the format truly behave as \"auto\".\n\n Will merge to 'master'.\n\n\n* ew/daemon-socket-keepalive (2016-05-25) 1 commit\n  (merged to 'next' on 2016-05-31 at c32acf1)\n + daemon: enable SO_KEEPALIVE for all sockets\n\n When \"git daemon\" is run without --[init-]timeout specified, a\n connection from a client that silently goes offline can hang around\n for a long time, wasting resources.  The socket-level KEEPALIVE has\n been enabled to allow the OS to notice such failed connections.\n\n Will merge to 'master'.\n\n\n* jk/upload-pack-hook (2016-06-02) 7 commits\n - upload-pack: provide a hook for running pack-objects\n - t1308: do not get fooled by symbolic links to the source tree\n - config: add a notion of \"scope\"\n - config: return configset value for current_config_ functions\n - config: set up config_source for command-line config\n - git_config_parse_parameter: refactor cleanup code\n - git_config_with_options: drop \"found\" counting\n\n Allow a custom \"git upload-pack\" replacement to respond to\n \"fetch/clone\" request.\n\n Still under discussion???\n ($gmane/295705).\n\n\n* rs/xdiff-hunk-with-func-line (2016-06-09) 9 commits\n  (merged to 'next' on 2016-06-10 at 9ff9ba8)\n + xdiff: fix merging of appended hunk with -W\n  (merged to 'next' on 2016-06-02 at 0c2e335)\n + grep: -W: don't extend context to trailing empty lines\n + t7810: add test for grep -W and trailing empty context lines\n + xdiff: don't trim common tail with -W\n + xdiff: -W: don't include common trailing empty lines in context\n + xdiff: ignore empty lines before added functions with -W\n + xdiff: handle appended chunks better with -W\n + xdiff: factor out match_func_rec()\n + t4051: rewrite, add more tests\n\n \"git show -W\" (extend hunks to cover the entire function, delimited\n by lines that match the \"funcname\" pattern) used to show the entire\n file when a change added an entire function at the end of the file,\n which has been fixed.\n\n Will merge to 'master'.\n\n\n* sb/submodule-misc-cleanups (2016-05-25) 1 commit\n  (merged to 'next' on 2016-05-31 at 0d07b9c)\n + submodule update: make use of the existing fetch_in_submodule function\n\n Minor simplification.\n\n Will merge to 'master'.\n\n\n* sb/submodule-default-paths (2016-06-14) 8 commits\n - completion: clone can recurse into submodules\n - clone: add --init-submodule=<pathspec> switch\n - submodule update: add `--init-default-path` switch\n - Merge branch 'sb/pathspec-label' into sb/submodule-default-paths\n - Merge branch 'jc/attr' into sb/submodule-default-paths\n - Merge branch 'sb/clone-shallow-passthru' into sb/submodule-default-paths\n - Merge branch 'sb/submodule-deinit-all' into sb/submodule-default-paths\n - Merge branch 'sb/submodule-parallel-update' into sb/submodule-default-paths\n (this branch uses jc/attr and sb/pathspec-label; is tangled with jc/attr-more.)\n\n Will hold.\n\n\n* ah/no-verify-signature-with-pull-rebase (2016-05-20) 1 commit\n  (merged to 'next' on 2016-05-31 at 30add83)\n + pull: warn on --verify-signatures with --rebase\n\n \"git pull --rebase --verify-signature\" learned to warn the user\n that \"--verify-signature\" is a no-op.\n\n Will merge to 'master'.\n\n\n* ep/http-curl-trace (2016-05-24) 2 commits\n - imap-send.c: introduce the GIT_TRACE_CURL enviroment variable\n - http.c: implement the GIT_TRACE_CURL environment variable\n\n HTTP transport gained an option to produce more detailed debugging\n trace.\n\n Will merge to 'next'.\n\n\n* jc/attr (2016-05-25) 18 commits\n  (merged to 'next' on 2016-05-31 at 5b2f08b)\n + attr: support quoting pathname patterns in C style\n + attr: expose validity check for attribute names\n + attr: add counted string version of git_attr()\n + attr: add counted string version of git_check_attr()\n + attr: retire git_check_attrs() API\n + attr: convert git_check_attrs() callers to use the new API\n + attr: convert git_all_attrs() to use \"struct git_attr_check\"\n + attr: (re)introduce git_check_attr() and struct git_attr_check\n + attr: rename function and struct related to checking attributes\n + attr.c: plug small leak in parse_attr_line()\n + attr.c: tighten constness around \"git_attr\" structure\n + attr.c: simplify macroexpand_one()\n + attr.c: mark where #if DEBUG ends more clearly\n + attr.c: complete a sentence in a comment\n + attr.c: explain the lack of attr-name syntax check in parse_attr()\n + attr.c: update a stale comment on \"struct match_attr\"\n + attr.c: use strchrnul() to scan for one line\n + commit.c: use strchrnul() to scan for one line\n (this branch is used by jc/attr-more, sb/pathspec-label and sb/submodule-default-paths.)\n\n The attributes API has been updated so that it can later be\n optimized using the knowledge of which attributes are queried.\n\n Will eject from 'next'.\n The updated API needs further rethinking.\n\n\n* cc/apply-introduce-state (2016-06-06) 50 commits\n  (merged to 'next' on 2016-06-06 at 9f6bdcb)\n + builtin/apply: remove misleading comment on lock_file field\n  (merged to 'next' on 2016-06-03 at 1ab0cf9)\n + builtin/apply: move 'newfd' global into 'struct apply_state'\n + builtin/apply: add 'lock_file' pointer into 'struct apply_state'\n + builtin/apply: move applying patches into apply_all_patches()\n + builtin/apply: move 'state' check into check_apply_state()\n + builtin/apply: move 'symlink_changes' global into 'struct apply_state'\n + builtin/apply: move 'fn_table' global into 'struct apply_state'\n + builtin/apply: move 'state_linenr' global into 'struct apply_state'\n + builtin/apply: move 'max_change' and 'max_len' into 'struct apply_state'\n + builtin/apply: move 'ws_ignore_action' into 'struct apply_state'\n + builtin/apply: move 'ws_error_action' into 'struct apply_state'\n + builtin/apply: move 'applied_after_fixing_ws' into 'struct apply_state'\n + builtin/apply: move 'squelch_whitespace_errors' into 'struct apply_state'\n + builtin/apply: remove whitespace_option arg from set_default_whitespace_mode()\n + builtin/apply: move 'whitespace_option' into 'struct apply_state'\n + builtin/apply: move 'whitespace_error' global into 'struct apply_state'\n + builtin/apply: move 'root' global into 'struct apply_state'\n + builtin/apply: move 'p_value_known' global into 'struct apply_state'\n + builtin/apply: move 'p_value' global into 'struct apply_state'\n + builtin/apply: move 'has_include' global into 'struct apply_state'\n + builtin/apply: move 'limit_by_name' global into 'struct apply_state'\n + builtin/apply: move 'patch_input_file' global into 'struct apply_state'\n + builtin/apply: move 'apply' global into 'struct apply_state'\n + builtin/apply: move 'p_context' global into 'struct apply_state'\n + builtin/apply: move 'fake_ancestor' global into 'struct apply_state'\n + builtin/apply: move 'line_termination' global into 'struct apply_state'\n + builtin/apply: move 'unsafe_paths' global into 'struct apply_state'\n + builtin/apply: move 'no_add' global into 'struct apply_state'\n + builtin/apply: move 'threeway' global into 'struct apply_state'\n + builtin/apply: move 'summary' global into 'struct apply_state'\n + builtin/apply: move 'numstat' global into 'struct apply_state'\n + builtin/apply: move 'diffstat' global into 'struct apply_state'\n + builtin/apply: move 'cached' global into 'struct apply_state'\n + builtin/apply: move 'allow_overlap' global into 'struct apply_state'\n + builtin/apply: move 'update_index' global into 'struct apply_state'\n + builtin/apply: move 'apply_verbosely' global into 'struct apply_state'\n + builtin/apply: move 'apply_with_reject' global into 'struct apply_state'\n + builtin/apply: move 'apply_in_reverse' global into 'struct apply_state'\n + builtin/apply: move 'check_index' global into 'struct apply_state'\n + builtin/apply: move 'check' global into 'struct apply_state'\n + builtin/apply: move 'unidiff_zero' global into 'struct apply_state'\n + builtin/apply: move 'state' init into init_apply_state()\n + builtin/apply: introduce 'struct apply_state' to start libifying\n + builtin/apply: move 'read_stdin' global into cmd_apply()\n + builtin/apply: move 'options' variable into cmd_apply()\n + builtin/apply: extract line_by_line_fuzzy_match() from match_fragment()\n + builtin/apply: avoid local variable shadowing 'len' parameter\n + builtin/apply: avoid parameter shadowing 'linenr' global\n + builtin/apply: avoid parameter shadowing 'p_value' global\n + builtin/apply: make gitdiff_verify_name() return void\n\n The \"git apply\" standalone program is being libified; this is the\n first step to move many state variables into a structure that can\n be explicitly (re)initialized to make the machinery callable more\n than once.\n\n The next step that moves some remaining state variables into the\n structure and turns die()s into an error return that propagates up\n to the caller is not queued yet but in flight.  It would be good to\n review the above first and give the remainder of the series a solid\n base to build on.\n\n Will hold.\n\n\n* pb/bisect (2016-05-24) 3 commits\n - bisect--helper: `write_terms` shell function in C\n - bisect: rewrite `check_term_format` shell function in C\n - bisect--helper: use OPT_CMDMODE instead of OPT_BOOL\n\n Beginning of GSoC \"git bisect\" project.\n\n I know another topic is getting rerolled many times on top of this;\n are people happy with these three patches?  If so, will merge to\n 'next'.\n\n\n* sb/pathspec-label (2016-06-03) 6 commits\n  (merged to 'next' on 2016-06-03 at 362f097)\n + pathspec: disable preload-index when attribute pathspec magic is in use\n + pathspec: allow escaped query values\n  (merged to 'next' on 2016-05-31 at e72b604)\n + pathspec: allow querying for attributes\n + pathspec: move prefix check out of the inner loop\n + pathspec: move long magic parsing out of prefix_pathspec\n + Documentation: fix a typo\n (this branch is used by sb/submodule-default-paths; uses jc/attr; is tangled with jc/attr-more.)\n\n The pathspec mechanism learned \":(attr:X)$pattern\" pathspec magic\n to limit paths that match $pattern further by attribute settings.\n The preload-index mechanism is disabled when the new pathspec magic\n is in use (at least for now), because the attribute subsystem is\n not thread-ready.\n\n Will eject from 'next'.\n The jc/attr topic that this depends on needs to be redone.\n\n\n* nd/worktree-cleanup-post-head-protection (2016-05-24) 6 commits\n - worktree: simplify prefixing paths\n - worktree: avoid 0{40}, too many zeroes, hard to read\n - worktree.c: use is_dot_or_dotdot()\n - git-worktree.txt: keep subcommand listing in alphabetical order\n - worktree.c: rewrite mark_current_worktree() to avoid strbuf\n - completion: support git-worktree\n (this branch is used by nd/worktree-lock.)\n\n Further preparatory clean-up for \"worktree\" feature.\n\n Will merge to 'next'.\n\n\n* mh/split-under-lock (2016-05-13) 33 commits\n  (merged to 'next' on 2016-06-03 at 2e71330)\n + lock_ref_sha1_basic(): only handle REF_NODEREF mode\n + commit_ref_update(): remove the flags parameter\n + lock_ref_for_update(): don't resolve symrefs\n + lock_ref_for_update(): don't re-read non-symbolic references\n + refs: resolve symbolic refs first\n + ref_transaction_update(): check refname_is_safe() at a minimum\n + unlock_ref(): move definition higher in the file\n + lock_ref_for_update(): new function\n + add_update(): initialize the whole ref_update\n + verify_refname_available(): adjust constness in declaration\n + refs: don't dereference on rename\n + refs: allow log-only updates\n + delete_branches(): use resolve_refdup()\n + ref_transaction_commit(): correctly report close_ref() failure\n + ref_transaction_create(): disallow recursive pruning\n + refs: make error messages more consistent\n + lock_ref_sha1_basic(): remove unneeded local variable\n + read_raw_ref(): move docstring to header file\n + read_raw_ref(): improve docstring\n + read_raw_ref(): rename symref argument to referent\n + read_raw_ref(): clear *type at start of function\n + read_raw_ref(): rename flags argument to type\n + ref_transaction_commit(): remove local variable n\n + rename_ref(): remove unneeded local variable\n + commit_ref_update(): write error message to *err, not stderr\n + refname_is_safe(): insist that the refname already be normalized\n + refname_is_safe(): don't allow the empty string\n + refname_is_safe(): use skip_prefix()\n + remove_dir_recursively(): add docstring\n + safe_create_leading_directories(): improve docstring\n + read_raw_ref(): don't get confused by an empty directory\n + commit_ref(): if there is an empty dir in the way, delete it\n + t1404: demonstrate a bug resolving references\n (this branch is used by mh/ref-iterators, mh/ref-store and mh/update-ref-errors.)\n\n Further preparatory work on the refs API before the pluggable\n backend series can land.\n\n Will merge to 'master'.\n\n\n* ew/fast-import-unpack-limit (2016-05-29) 2 commits\n  (merged to 'next' on 2016-05-29 at af32aba)\n + fast-import: invalidate pack_id references after loosening\n  (merged to 'next' on 2016-05-11 at ffd4efb)\n + fast-import: implement unpack limit\n\n \"git fast-import\" learned the same performance trick to avoid\n creating too small a packfile as \"git fetch\" and \"git push\" have,\n using *.unpackLimit configuration.\n\n Will merge to 'master'.\n\n\n* jc/send-email-skip-backup (2016-04-12) 1 commit\n - send-email: detect and offer to skip backup files\n\n A careless invocation of \"git send-email directory/\" after editing\n 0001-change.patch with an editor often ends up sending both\n 0001-change.patch and its backup file, 0001-change.patch~, causing\n embarrassment and a minor confusion.  Detect such an input and\n offer to skip the backup files when sending the patches out.\n\n Will merge to 'next'.\n Perhaps people will enhance it more once it gains more visibility.\n\n\n* kn/ref-filter-branch-list (2016-05-17) 17 commits\n - branch: implement '--format' option\n - branch: use ref-filter printing APIs\n - branch, tag: use porcelain output\n - ref-filter: allow porcelain to translate messages in the output\n - ref-filter: add `:dir` and `:base` options for ref printing atoms\n - ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()\n - ref-filter: introduce symref_atom_parser() and refname_atom_parser()\n - ref-filter: introduce refname_atom_parser_internal()\n - ref-filter: make \"%(symref)\" atom work with the ':short' modifier\n - ref-filter: add support for %(upstream:track,nobracket)\n - ref-filter: make %(upstream:track) prints \"[gone]\" for invalid upstreams\n - ref-filter: introduce format_ref_array_item()\n - ref-filter: move get_head_description() from branch.c\n - ref-filter: modify \"%(objectname:short)\" to take length\n - ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)\n - ref-filter: include reference to 'used_atom' within 'atom_value'\n - ref-filter: implement %(if), %(then), and %(else) atoms\n\n The code to list branches in \"git branch\" has been consolidated\n with the more generic ref-filter API.\n\n Rerolled.\n This also really needs review.\n\n\n* dt/index-helper (2016-05-20) 20 commits\n - index-helper: indexhelper.exitafter config\n - trace: measure where the time is spent in the index-heavy operations\n - index-helper: optionally automatically run\n - index-helper: autorun mode\n - index-helper: don't run if already running\n - index-helper: kill mode\n - watchman: add a config option to enable the extension\n - unpack-trees: preserve index extensions\n - update-index: enable/disable watchman support\n - index-helper: use watchman to avoid refreshing index with lstat()\n - watchman: support watchman to reduce index refresh cost\n - read-cache: add watchman 'WAMA' extension\n - index-helper: log warnings\n - index-helper: add --detach\n - daemonize(): set a flag before exiting the main process\n - index-helper: add --strict\n - index-helper: new daemon for caching index and related stuff\n - pkt-line: add gentle version of packet_write\n - read-cache: allow to keep mmap'd memory after reading\n - read-cache.c: fix constness of verify_hdr()\n\n A new \"index-helper\" daemon has been introduced to give newly\n spawned Git process a quicker access to the data in the index, and\n optionally interface with the watchman daemon to further reduce the\n refresh cost.\n\n Are people happy with this version?  If so will merge to 'next'.\n ($gmane/295106).\n\n\n* jc/bundle (2016-03-03) 6 commits\n - index-pack: --clone-bundle option\n - Merge branch 'jc/index-pack' into jc/bundle\n - bundle v3: the beginning\n - bundle: keep a copy of bundle file name in the in-core bundle header\n - bundle: plug resource leak\n - bundle doc: 'verify' is not about verifying the bundle\n\n The beginning of \"split bundle\", which could be one of the\n ingredients to allow \"git clone\" traffic off of the core server\n network to CDN.\n\n While I think it would make it easier for people to experiment and\n build on if the topic is merged to 'next', I am at the same time a\n bit reluctant to merge an unproven new topic that introduces a new\n file format, which we may end up having to support til the end of\n time.  Comments?\n\n\n* jc/merge-drop-old-syntax (2015-04-29) 1 commit\n - merge: drop 'git merge <message> HEAD <commit>' syntax\n\n Stop supporting \"git merge <message> HEAD <commit>\" syntax that has\n been deprecated since October 2007, and issues a deprecation\n warning message since v2.5.0.\n\n It has been reported that git-gui still uses the deprecated syntax,\n which needs to be fixed before this final step can proceed.\n ($gmane/282594)\n\n--------------------------------------------------\n[Discarded]\n\n* js/am-3-merge-recursive-direct (2015-10-12) 2 commits\n . am: make a direct call to merge_recursive\n . merge_recursive_options: introduce the \"gently\" flag\n\n The merge_recursive_generic() function has been made a bit safer to\n call from inside a process.  \"git am -3\" was taught to make a direct\n call to the function when falling back to three-way merge.\n\n Being able to make a direct call would be good in general, but as a\n performance thing, the change needs to be backed up by numbers.\n\n I haven't gone through the \"gently\" change with fine toothed comb;\n I can see that the change avoids calling die(), but I haven't made\n sure that the program states (e.g. what's in the in-core index) are\n adjusted sensibly when it returns to the caller instead of dying,\n or the codepaths that used to die() are free of resource leaks.\n The original code certainly did not care the program states at the\n point of dying exactly because it knew it is going to exit, but now\n they have to care, and they need to be audited.\n\n Has a lot of conflict when merged to 'pu' these days, so let's\n eject it from our tree for now.\n\n Will discard.\n ($gmane/292205)\n\n\n* nd/i-t-a-commitable (2016-06-06) 3 commits\n . commit: don't count i-t-a entries when checking if the new commit is empty\n . Resurrect \"diff-lib.c: adjust position of i-t-a entries in diff\"\n . diff.h: extend \"flags\" field to 64 bits because we're out of bits\n\n \"rm .git/index && git add -N * && git commit\" allows you to create\n an empty commit without --allow-empty; attempt to forbid it.\n\n Retracted.\n Will discard.\n ($gmane/297362)\n\n\n* jc/merge-impossible-no-commit (2016-04-26) 2 commits\n . merge: warn --no-commit merge when no new commit is created\n . merge: do not contaminate option_commit with --squash\n\n \"git merge --no-commit\" silently succeeded when there is no need to\n create any commit, either when you are more recent than the commit\n you tried to merge, or you can fast-forward to the commit you tried\n to merge.  The command gives a warning message in such cases.\n\n Just tying loose ends in a discussion.  Unless somebody else\n champions this topic, I'll drop it.\n\n Will discard.\n\n\n* bc/cocci-object-id (2016-06-06) 8 commits\n . merge-recursive: convert merge_recursive_generic to object_id\n . merge-recursive: convert leaf functions to use struct object_id\n . merge-recursive: convert struct merge_file_info to object_id\n . merge-recursive: convert struct stage_data to use object_id\n . Rename struct diff_filespec's sha1_valid member.\n . Convert struct diff_filespec to struct object_id\n . Apply standard object_id Coccinelle transformations.\n . Add basic Coccinelle transforms.\n\n Move from \"unsigned char [20]\" to \"struct object_id\" continues,\n with help from an automated tool.\n\n Will discard.\n ($gmane/296749)\n\n\n* az/p4-bare-no-rebase (2016-02-19) 1 commit\n - git-p4.py: Don't try to rebase on submit from bare repository\n\n \"git p4 submit\" attempts to do a rebase, which would fail if done\n in a bare repository.  Not doing this rebase would paper over the\n failure, which is what this patch does, but it is unclear what the\n side effect of not rebasing is.\n\n Retracted.\n ($gmane/296722)\n"},{"id":"289442","messageId":"CAFZEwPO3VA0O-t4fL_tX68QibJF7KowzQuimTj0dbrQ6NX8yPA@mail.gmail.com","threadId":"42635","inReplyTo":"xmqqk2ho33ig.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-06-17T13:25:22Z","receivedAt":"2016-06-17T13:25:27Z","isPatch":false,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"Hey Junio,\n\nOn Fri, Jun 17, 2016 at 8:50 AM, Junio C Hamano <gitster@pobox.com> wrote:\n\n> * pb/bisect (2016-05-24) 3 commits\n>  - bisect--helper: `write_terms` shell function in C\n>  - bisect: rewrite `check_term_format` shell function in C\n>  - bisect--helper: use OPT_CMDMODE instead of OPT_BOOL\n>\n>  Beginning of GSoC \"git bisect\" project.\n>\n>  I know another topic is getting rerolled many times on top of this;\n>  are people happy with these three patches?  If so, will merge to\n>  'next'.\n\n\nThis matches the last re-roll[1] I did which looks good to me. Thanks!\nThough I was under the impression that the whole topic would be merged\nto next after the completion of the GSoC project because the test\nsuite seems lacking at a few places (pointed out by Eric). So I had\nintended to do the coverage tests after the completion so that I could\nuse the gcov rather than setting up a coverage tool for shell scripts.\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/295518\n\nRegards,\nPranit Bauva\n"},{"id":"289465","messageId":"loom.20160617T194406-197@post.gmane.org","threadId":"42635","inReplyTo":"xmqqk2ho33ig.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Vasco Almeida","fromEmail":"vascomalmeida@sapo.pt","sentAt":"2016-06-17T17:55:38Z","receivedAt":"2016-06-17T17:56:14Z","isPatch":false,"sender":{"key":"vascomalmeida@sapo.pt","avatar":"https://avatars.githubusercontent.com/u/9001556?v=4"},"body":"Junio C Hamano <gitster <at> pobox.com> writes:\n> * va/i18n-even-more (2016-06-07) 38 commits\n>  - i18n: branch: mark comment when editing branch description for translation\n>  - i18n: unmark die messages for translation\n>  - i18n: submodule: escape shell variables inside eval_gettext\n>  - i18n: submodule: join strings marked for translation\n>  - i18n: init-db: join message pieces\n[snip]\n>  - i18n: builtin/remote.c: fix mark for translation\n>  - Merge branch 'jc/t2300-setup' into HEAD\n\nPatch \"i18n: init-db: join message pieces\" breaks test\nt0204-gettext-reencode-sanity.sh because it changes message id used in\nIcelandic translation used on that test.\nPlease, don't merge this series, I'm going to send a re-roll (v5).\n\nDiscussion: http://mid.gmane.org/1562644.BnkjqA6nsN@linux-omuo\n\n"},{"id":"289522","messageId":"1634E84E-5260-4F7B-A74F-AF5D3A7C0181@gmail.com","threadId":"42635","inReplyTo":"xmqqk2ho33ig.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-06-17T22:05:52Z","receivedAt":"2016-06-17T22:05:59Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 17 Jun 2016, at 05:20, Junio C Hamano <gitster@pobox.com> wrote:\n> \n> ...\n> \n> * mh/split-under-lock (2016-05-13) 33 commits\n>  (merged to 'next' on 2016-06-03 at 2e71330)\n> + lock_ref_sha1_basic(): only handle REF_NODEREF mode\n> + commit_ref_update(): remove the flags parameter\n> + lock_ref_for_update(): don't resolve symrefs\n> + lock_ref_for_update(): don't re-read non-symbolic references\n> + refs: resolve symbolic refs first\n> + ref_transaction_update(): check refname_is_safe() at a minimum\n> + unlock_ref(): move definition higher in the file\n> + lock_ref_for_update(): new function\n> + add_update(): initialize the whole ref_update\n> + verify_refname_available(): adjust constness in declaration\n> + refs: don't dereference on rename\n> + refs: allow log-only updates\n> + delete_branches(): use resolve_refdup()\n> + ref_transaction_commit(): correctly report close_ref() failure\n> + ref_transaction_create(): disallow recursive pruning\n> + refs: make error messages more consistent\n> + lock_ref_sha1_basic(): remove unneeded local variable\n> + read_raw_ref(): move docstring to header file\n> + read_raw_ref(): improve docstring\n> + read_raw_ref(): rename symref argument to referent\n> + read_raw_ref(): clear *type at start of function\n> + read_raw_ref(): rename flags argument to type\n> + ref_transaction_commit(): remove local variable n\n> + rename_ref(): remove unneeded local variable\n> + commit_ref_update(): write error message to *err, not stderr\n> + refname_is_safe(): insist that the refname already be normalized\n> + refname_is_safe(): don't allow the empty string\n> + refname_is_safe(): use skip_prefix()\n> + remove_dir_recursively(): add docstring\n> + safe_create_leading_directories(): improve docstring\n> + read_raw_ref(): don't get confused by an empty directory\n> + commit_ref(): if there is an empty dir in the way, delete it\n> + t1404: demonstrate a bug resolving references\n> (this branch is used by mh/ref-iterators, mh/ref-store and mh/update-ref-errors.)\n> \n> Further preparatory work on the refs API before the pluggable\n> backend series can land.\n> \n> Will merge to 'master'.\n\nThis topic seems break two git-p4 tests (t9801 and t9803) on next:\nhttps://travis-ci.org/git/git/jobs/137333785\n\nAccording to git bisect the commit \"ref_transaction_update(): \ncheck refname_is_safe() at a minimum\" (3da1f3) introduces the problem: \nhttps://s3.amazonaws.com/archive.travis-ci.org/jobs/138457628/log.txt\n(scroll all the way down to see the bisecting)\n\n- Lars"},{"id":"289523","messageId":"xmqqfusbzchr.fsf@gitster.mtv.corp.google.com","threadId":"42635","inReplyTo":"1634E84E-5260-4F7B-A74F-AF5D3A7C0181@gmail.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-17T22:17:36Z","receivedAt":"2016-06-17T22:17:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider <larsxschneider@gmail.com> writes:\n\n>> On 17 Jun 2016, at 05:20, Junio C Hamano <gitster@pobox.com> wrote:\n>> \n>> ...\n>> \n>> * mh/split-under-lock (2016-05-13) 33 commits\n>>  (merged to 'next' on 2016-06-03 at 2e71330)\n>> + lock_ref_sha1_basic(): only handle REF_NODEREF mode\n>> + ...\n>> + t1404: demonstrate a bug resolving references\n>> (this branch is used by mh/ref-iterators, mh/ref-store and mh/update-ref-errors.)\n>> \n>> Further preparatory work on the refs API before the pluggable\n>> backend series can land.\n>> \n>> Will merge to 'master'.\n>\n> This topic seems break two git-p4 tests (t9801 and t9803) on next:\n> https://travis-ci.org/git/git/jobs/137333785\n>\n> According to git bisect the commit \"ref_transaction_update(): \n> check refname_is_safe() at a minimum\" (3da1f3) introduces the problem: \n> https://s3.amazonaws.com/archive.travis-ci.org/jobs/138457628/log.txt\n> (scroll all the way down to see the bisecting)\n\nThanks.  Let's hold it and all of its dependents to see what is\ngoing on.\n\n"},{"id":"289561","messageId":"5764CBA8.5070303@alum.mit.edu","threadId":"42635","inReplyTo":"xmqqk2ho33ig.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2016-06-18T04:18:48Z","receivedAt":"2016-06-18T04:18:54Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/17/2016 05:20 AM, Junio C Hamano wrote:\n> [...]\n> * mh/ref-iterators (2016-06-03) 13 commits\n>   (merged to 'next' on 2016-06-06 at c8e79dc)\n>  + for_each_reflog(): reimplement using iterators\n>  + dir_iterator: new API for iterating over a directory tree\n>  + for_each_reflog(): don't abort for bad references\n>  + do_for_each_ref(): reimplement using reference iteration\n>  + refs: introduce an iterator interface\n>  + ref_resolves_to_object(): new function\n>  + entry_resolves_to_object(): rename function from ref_resolves_to_object()\n>  + get_ref_cache(): only create an instance if there is a submodule\n>  + remote rm: handle symbolic refs correctly\n>  + delete_refs(): add a flags argument\n>  + refs: use name \"prefix\" consistently\n>  + do_for_each_ref(): move docstring to the header file\n>  + refs: remove unnecessary \"extern\" keywords\n>  (this branch is used by mh/ref-store; uses mh/split-under-lock; is tangled with mh/update-ref-errors.)\n> \n>  The API to iterate over all the refs (i.e. for_each_ref(), etc.)\n>  has been revamped.\n> \n>  Will merge to 'master'.\n\nIt would be preferable (though not critical) to use the promised v3,\nwhich I just sent [1]. This includes some minor improvements, described\nhere [2]. This is also available from my GitHub fork [3] as branch\n\"ref-iterators\".\n\n> * mh/split-under-lock (2016-05-13) 33 commits\n>   (merged to 'next' on 2016-06-03 at 2e71330)\n>  + lock_ref_sha1_basic(): only handle REF_NODEREF mode\n>  + commit_ref_update(): remove the flags parameter\n>  + lock_ref_for_update(): don't resolve symrefs\n>  + lock_ref_for_update(): don't re-read non-symbolic references\n>  + refs: resolve symbolic refs first\n>  + ref_transaction_update(): check refname_is_safe() at a minimum\n>  + unlock_ref(): move definition higher in the file\n>  + lock_ref_for_update(): new function\n>  + add_update(): initialize the whole ref_update\n>  + verify_refname_available(): adjust constness in declaration\n>  + refs: don't dereference on rename\n>  + refs: allow log-only updates\n>  + delete_branches(): use resolve_refdup()\n>  + ref_transaction_commit(): correctly report close_ref() failure\n>  + ref_transaction_create(): disallow recursive pruning\n>  + refs: make error messages more consistent\n>  + lock_ref_sha1_basic(): remove unneeded local variable\n>  + read_raw_ref(): move docstring to header file\n>  + read_raw_ref(): improve docstring\n>  + read_raw_ref(): rename symref argument to referent\n>  + read_raw_ref(): clear *type at start of function\n>  + read_raw_ref(): rename flags argument to type\n>  + ref_transaction_commit(): remove local variable n\n>  + rename_ref(): remove unneeded local variable\n>  + commit_ref_update(): write error message to *err, not stderr\n>  + refname_is_safe(): insist that the refname already be normalized\n>  + refname_is_safe(): don't allow the empty string\n>  + refname_is_safe(): use skip_prefix()\n>  + remove_dir_recursively(): add docstring\n>  + safe_create_leading_directories(): improve docstring\n>  + read_raw_ref(): don't get confused by an empty directory\n>  + commit_ref(): if there is an empty dir in the way, delete it\n>  + t1404: demonstrate a bug resolving references\n>  (this branch is used by mh/ref-iterators, mh/ref-store and mh/update-ref-errors.)\n> \n>  Further preparatory work on the refs API before the pluggable\n>  backend series can land.\n> \n>  Will merge to 'master'.\n\nPlease make sure to pick up the important bugfix discussed here [4],\nwhich is integrated into branch \"split-under-lock\" on my GitHub fork [3].\n\nMichael\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/297625\n[2]\nhttp://thread.gmane.org/gmane.comp.version-control.git/296322/focus=296883\n[3] https://github.com/mhagger/git\n[4] http://article.gmane.org/gmane.comp.version-control.git/297174\n\n"},{"id":"289579","messageId":"57658033.7060402@alum.mit.edu","threadId":"42635","inReplyTo":"1634E84E-5260-4F7B-A74F-AF5D3A7C0181@gmail.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2016-06-18T17:09:07Z","receivedAt":"2016-06-18T17:10:51Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/18/2016 12:05 AM, Lars Schneider wrote:\n> \n>> On 17 Jun 2016, at 05:20, Junio C Hamano <gitster@pobox.com> wrote:\n>>\n>> ...\n>>\n>> * mh/split-under-lock (2016-05-13) 33 commits\n>>  (merged to 'next' on 2016-06-03 at 2e71330)\n>> [...]\n> \n> This topic seems break two git-p4 tests (t9801 and t9803) on next:\n> https://travis-ci.org/git/git/jobs/137333785\n> \n> According to git bisect the commit \"ref_transaction_update(): \n> check refname_is_safe() at a minimum\" (3da1f3) introduces the problem: \n> https://s3.amazonaws.com/archive.travis-ci.org/jobs/138457628/log.txt\n> (scroll all the way down to see the bisecting)\n\nThanks for the bug report. I'll look into this as soon as I have the chance.\n\nDo you happen to know if there is a way to get a copy of p4 without\npaying for it so that I can run the tests locally?\n\nGiven the commit that you bisected to, one likely possibility is that\nthe test is trying to create a reference with an unsafe name, in the\nsense of `refname_is_safe()`. Is that possible? Do you happen to know\nwhat Git reference names that test case wants to create?\n\nMichael\n\n"},{"id":"289580","messageId":"xmqqziqixsti.fsf@gitster.mtv.corp.google.com","threadId":"42635","inReplyTo":"5764CBA8.5070303@alum.mit.edu","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-18T18:20:09Z","receivedAt":"2016-06-18T18:21:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> On 06/17/2016 05:20 AM, Junio C Hamano wrote:\n>> [...]\n>> * mh/ref-iterators (2016-06-03) 13 commits\n>>   (merged to 'next' on 2016-06-06 at c8e79dc)\n>>  + ...\n>>  (this branch is used by mh/ref-store; uses mh/split-under-lock; is tangled with mh/update-ref-errors.)\n>> \n>>  The API to iterate over all the refs (i.e. for_each_ref(), etc.)\n>>  has been revamped.\n>> \n>>  Will merge to 'master'.\n>\n> It would be preferable (though not critical) to use the promised v3,\n> which I just sent [1]. This includes some minor improvements, described\n> here [2]. This is also available from my GitHub fork [3] as branch\n> \"ref-iterators\".\n>\n>> * mh/split-under-lock (2016-05-13) 33 commits\n>>   (merged to 'next' on 2016-06-03 at 2e71330)\n>>  + lock_ref_sha1_basic(): only handle REF_NODEREF mode\n>>  + ...\n>>  Will merge to 'master'.\n>\n> Please make sure to pick up the important bugfix discussed here [4],\n> which is integrated into branch \"split-under-lock\" on my GitHub fork [3].\n\nGood timing. I was planning to kick split-under-lock and any of its\ndependents temporarily out of 'next', so that fixes can choose not\nto be incremental, and dependent topics can be rebased on top of the\nfixed fondation.  Even if we do incremental, [4] is not sufficient\nmaterial for me to write a log message for.\n\nSo people who reviewed what has been in 'next' can revisit [4] and\ngive review comments, while I could just pick up the history\nmentioned there, i.e.\n\n    git checkout pu\n    git pull git://github.com/mhagger/git +split-under-lock:mh/split-under-lock\n\nand we can start from there?\n\nThanks.\n\n>\n> Michael\n>\n> [1] http://thread.gmane.org/gmane.comp.version-control.git/297625\n> [2]\n> http://thread.gmane.org/gmane.comp.version-control.git/296322/focus=296883\n> [3] https://github.com/mhagger/git\n> [4] http://article.gmane.org/gmane.comp.version-control.git/297174\n"},{"id":"289611","messageId":"576650E7.70107@alum.mit.edu","threadId":"42635","inReplyTo":"1634E84E-5260-4F7B-A74F-AF5D3A7C0181@gmail.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2016-06-19T07:59:35Z","receivedAt":"2016-06-19T08:00:17Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/18/2016 12:05 AM, Lars Schneider wrote:\n> \n>> On 17 Jun 2016, at 05:20, Junio C Hamano <gitster@pobox.com> wrote:\n>>\n>> ...\n>>\n>> * mh/split-under-lock (2016-05-13) 33 commits\n>>  (merged to 'next' on 2016-06-03 at 2e71330)\n>> + lock_ref_sha1_basic(): only handle REF_NODEREF mode\n>> + commit_ref_update(): remove the flags parameter\n>> + lock_ref_for_update(): don't resolve symrefs\n>> + lock_ref_for_update(): don't re-read non-symbolic references\n>> + refs: resolve symbolic refs first\n>> + ref_transaction_update(): check refname_is_safe() at a minimum\n>> + unlock_ref(): move definition higher in the file\n>> + lock_ref_for_update(): new function\n>> + add_update(): initialize the whole ref_update\n>> + verify_refname_available(): adjust constness in declaration\n>> + refs: don't dereference on rename\n>> + refs: allow log-only updates\n>> + delete_branches(): use resolve_refdup()\n>> + ref_transaction_commit(): correctly report close_ref() failure\n>> + ref_transaction_create(): disallow recursive pruning\n>> + refs: make error messages more consistent\n>> + lock_ref_sha1_basic(): remove unneeded local variable\n>> + read_raw_ref(): move docstring to header file\n>> + read_raw_ref(): improve docstring\n>> + read_raw_ref(): rename symref argument to referent\n>> + read_raw_ref(): clear *type at start of function\n>> + read_raw_ref(): rename flags argument to type\n>> + ref_transaction_commit(): remove local variable n\n>> + rename_ref(): remove unneeded local variable\n>> + commit_ref_update(): write error message to *err, not stderr\n>> + refname_is_safe(): insist that the refname already be normalized\n>> + refname_is_safe(): don't allow the empty string\n>> + refname_is_safe(): use skip_prefix()\n>> + remove_dir_recursively(): add docstring\n>> + safe_create_leading_directories(): improve docstring\n>> + read_raw_ref(): don't get confused by an empty directory\n>> + commit_ref(): if there is an empty dir in the way, delete it\n>> + t1404: demonstrate a bug resolving references\n>> (this branch is used by mh/ref-iterators, mh/ref-store and mh/update-ref-errors.)\n>>\n>> Further preparatory work on the refs API before the pluggable\n>> backend series can land.\n>>\n>> Will merge to 'master'.\n> \n> This topic seems break two git-p4 tests (t9801 and t9803) on next:\n> https://travis-ci.org/git/git/jobs/137333785\n> \n> According to git bisect the commit \"ref_transaction_update(): \n> check refname_is_safe() at a minimum\" (3da1f3) introduces the problem: \n> https://s3.amazonaws.com/archive.travis-ci.org/jobs/138457628/log.txt\n> (scroll all the way down to see the bisecting)\n> \n> - Lars\n> \n\nLars,\n\nAccording to [1], something in that test seems to have been trying to run\n\n    git update-ref -d git-p4-tmp/6\n\nSimilarly in the other failed test.\n\nBecause `update-ref` doesn't do DWIM for reference names, this is *not*\nexpanded to `refs/heads/git-p4-tmp/6` or something. Previously this\ncommand would have quietly failed to do anything. But after\n\"ref_transaction_update(): check refname_is_safe() at a minimum\", `git\nupdate-ref` notices that `git/p4/tmp/6` is not a safe refname (according\nto `refname_is_safe()` [2]), and correctly fails with an error message.\n\nEven before this change, Git didn't allow such references to be created\nor updated. So I think this test failure is revealing an error in `git\np4 clone` that went undetected before this change.\n\nPlease let me know whether you agree. If so, it is realistic to fix\n`git-p4` promptly? This failure is currently blocking\nmh/split-under-lock, so if `git-p4` can't be fixed, then I'd have to\neither disable t9801 and t9803 in this patch series, or omit the\n`refname_is_safe()` check.\n\nIn the interest of backwards compatibility, I considered making `git\nupdate-ref -d` continue to fail silently for NOOP operations with unsafe\nrefnames (one of the requirements being that no old_oid is specified).\nBut I think that would be giving the wrong signal to scripts that are\ndoing something that is invalid but pausible, like trying to delete the\nreference `../$(basename $PWD)/refs/heads/foo`. Such scripts would be\nmisled into thinking the deletion was successful. And yet treating\nplausibly-sensible requests differently than obviously bogus requests\nseems like a path to madness.\n\nMichael\n\n[1] https://travis-ci.org/git/git/jobs/137333785#L2025-L2026\n[2]\nhttps://github.com/mhagger/git/blob/7a418f3a17b95746eb94cfd55f4fe0385d058777/refs.c#L121-L151\n\n"},{"id":"289612","messageId":"57665497.3060100@alum.mit.edu","threadId":"42635","inReplyTo":"xmqqziqixsti.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2016-06-19T08:15:19Z","receivedAt":"2016-06-19T08:15:42Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/18/2016 08:20 PM, Junio C Hamano wrote:\n> Michael Haggerty <mhagger@alum.mit.edu> writes:\n> \n>> On 06/17/2016 05:20 AM, Junio C Hamano wrote:\n>>> [...]\n>>> * mh/ref-iterators (2016-06-03) 13 commits\n>>>   (merged to 'next' on 2016-06-06 at c8e79dc)\n>>>  + ...\n>>>  (this branch is used by mh/ref-store; uses mh/split-under-lock; is tangled with mh/update-ref-errors.)\n>>>\n>>>  The API to iterate over all the refs (i.e. for_each_ref(), etc.)\n>>>  has been revamped.\n>>>\n>>>  Will merge to 'master'.\n>>\n>> It would be preferable (though not critical) to use the promised v3,\n>> which I just sent [1]. This includes some minor improvements, described\n>> here [2]. This is also available from my GitHub fork [3] as branch\n>> \"ref-iterators\".\n>>\n>>> * mh/split-under-lock (2016-05-13) 33 commits\n>>>   (merged to 'next' on 2016-06-03 at 2e71330)\n>>>  + lock_ref_sha1_basic(): only handle REF_NODEREF mode\n>>>  + ...\n>>>  Will merge to 'master'.\n>>\n>> Please make sure to pick up the important bugfix discussed here [4],\n>> which is integrated into branch \"split-under-lock\" on my GitHub fork [3].\n> \n> Good timing. I was planning to kick split-under-lock and any of its\n> dependents temporarily out of 'next', so that fixes can choose not\n> to be incremental, and dependent topics can be rebased on top of the\n> fixed fondation.  Even if we do incremental, [4] is not sufficient\n> material for me to write a log message for.\n> \n> So people who reviewed what has been in 'next' can revisit [4] and\n> give review comments, while I could just pick up the history\n> mentioned there, i.e.\n> \n>     git checkout pu\n>     git pull git://github.com/mhagger/git +split-under-lock:mh/split-under-lock\n> \n> and we can start from there?\n\nSure. The branches in my GitHub fork already include all of the\nimprovements and fixes that I know of, and the only outstanding issue is\nthe one that Lars mentioned in this thread (which I believe to be a\nproblem in git-p4).\n\nBTW, there are still no conflicts between these branches\n(split-under-lock, update-ref-errors, ref-iterators, and ref-store) and\ncurrent master. Therefore, I don't see a need to rebase them onto\nmaster. But if you would prefer that I do so, just let me know.\n\nMichael\n\n"},{"id":"289626","messageId":"3E132EEE-CEBA-4C0D-A5C4-62F587A02225@gmail.com","threadId":"42635","inReplyTo":"576650E7.70107@alum.mit.edu","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-06-19T15:04:11Z","receivedAt":"2016-06-19T15:11:37Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 19 Jun 2016, at 09:59, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> \n> On 06/18/2016 12:05 AM, Lars Schneider wrote:\n>> \n>>> On 17 Jun 2016, at 05:20, Junio C Hamano <gitster@pobox.com> wrote:\n>>> \n>>> ...\n>>> \n>>> * mh/split-under-lock (2016-05-13) 33 commits\n>>> ...\n>>> \n>>> Further preparatory work on the refs API before the pluggable\n>>> backend series can land.\n>>> \n>>> Will merge to 'master'.\n>> \n>> This topic seems break two git-p4 tests (t9801 and t9803) on next:\n>> https://travis-ci.org/git/git/jobs/137333785\n>> \n>> According to git bisect the commit \"ref_transaction_update(): \n>> check refname_is_safe() at a minimum\" (3da1f3) introduces the problem: \n>> https://s3.amazonaws.com/archive.travis-ci.org/jobs/138457628/log.txt\n>> (scroll all the way down to see the bisecting)\n>> \n>> - Lars\n>> \n> \n> Lars,\n> \n> According to [1], something in that test seems to have been trying to run\n> \n>    git update-ref -d git-p4-tmp/6\n> \n> Similarly in the other failed test.\n> \n> Because `update-ref` doesn't do DWIM for reference names, this is *not*\n> expanded to `refs/heads/git-p4-tmp/6` or something. Previously this\n> command would have quietly failed to do anything. But after\n> \"ref_transaction_update(): check refname_is_safe() at a minimum\", `git\n> update-ref` notices that `git/p4/tmp/6` is not a safe refname (according\n> to `refname_is_safe()` [2]), and correctly fails with an error message.\n\nAll errors seem to be related to the Git-P4 branch import. I am no expert\nin that area because the branch import never worked for me (and I am puzzled\nto some extend how it is supposed to work given the differences how branches\nwork in Git and P4).\n\nThis is the offending call:\nhttps://github.com/git/git/blob/05219a1276341e72d8082d76b7f5ed394b7437a4/git-p4.py#L3464\n\nThis is only a cleanup call and we could make all tests work if we remove the\ncleanup and also the \"cleanup successful check\":\nhttps://github.com/git/git/blob/05219a1276341e72d8082d76b7f5ed394b7437a4/t/t9801-git-p4-branch.sh#L303\nhttps://github.com/git/git/blob/05219a1276341e72d8082d76b7f5ed394b7437a4/t/t9801-git-p4-branch.sh#L355\n\nI am a bit surprised that we do not see other errors given the fact \nthat the branch name is clearly invalid:\nhttps://github.com/git/git/blob/05219a1276341e72d8082d76b7f5ed394b7437a4/t/t9803-git-p4-shell-metachars.sh#L102\n\nI see two ways to proceed:\n\n(1) We remove the cleanup.\n\n(2) We sanitize the branch names (e.g. by removing invalid characters).\n@Michael: Is there a function to \"sanitize\" a given branch name already?\n\nOption 1 is trivial and option 2 (my preference) shouldn't be too hard. \nBut maybe Luke has some insights since he added the \"branch with shell char\" \ntest in 52a4880.\n\n\n> Even before this change, Git didn't allow such references to be created\n> or updated. So I think this test failure is revealing an error in `git\n> p4 clone` that went undetected before this change.\n> \n> Please let me know whether you agree. If so, it is realistic to fix\n> `git-p4` promptly? This failure is currently blocking\n> mh/split-under-lock, so if `git-p4` can't be fixed, then I'd have to\n> either disable t9801 and t9803 in this patch series, or omit the\n> `refname_is_safe()` check.\nI am looking into option 2.\n\n> \n> In the interest of backwards compatibility, I considered making `git\n> update-ref -d` continue to fail silently for NOOP operations with unsafe\n> refnames (one of the requirements being that no old_oid is specified).\n> But I think that would be giving the wrong signal to scripts that are\n> doing something that is invalid but pausible, like trying to delete the\n> reference `../$(basename $PWD)/refs/heads/foo`. Such scripts would be\n> misled into thinking the deletion was successful. And yet treating\n> plausibly-sensible requests differently than obviously bogus requests\n> seems like a path to madness.\nAgreed!\n\nCheers,\nLars"},{"id":"289628","messageId":"BC5163B8-7CF2-4106-9FBE-8CCD096252A2@gmail.com","threadId":"42635","inReplyTo":"3E132EEE-CEBA-4C0D-A5C4-62F587A02225@gmail.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-06-19T16:11:03Z","receivedAt":"2016-06-19T16:11:14Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 19 Jun 2016, at 17:04, Lars Schneider <larsxschneider@gmail.com> wrote:\n> \n> \n>> On 19 Jun 2016, at 09:59, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n>> \n>> On 06/18/2016 12:05 AM, Lars Schneider wrote:\n>>> \n>>>> On 17 Jun 2016, at 05:20, Junio C Hamano <gitster@pobox.com> wrote:\n>>>> \n>>>> ...\n>>>> \n>>>> * mh/split-under-lock (2016-05-13) 33 commits\n>>>> ...\n>>>> \n>>>> Further preparatory work on the refs API before the pluggable\n>>>> backend series can land.\n>>>> \n>>>> Will merge to 'master'.\n>>> \n>>> This topic seems break two git-p4 tests (t9801 and t9803) on next:\n>>> https://travis-ci.org/git/git/jobs/137333785\n>>> \n>>> According to git bisect the commit \"ref_transaction_update(): \n>>> check refname_is_safe() at a minimum\" (3da1f3) introduces the problem: \n>>> https://s3.amazonaws.com/archive.travis-ci.org/jobs/138457628/log.txt\n>>> (scroll all the way down to see the bisecting)\n>>> \n>>> - Lars\n>>> \n>> \n>> Lars,\n>> \n>> According to [1], something in that test seems to have been trying to run\n>> \n>>   git update-ref -d git-p4-tmp/6\n>> \n>> Similarly in the other failed test.\n>> \n>> Because `update-ref` doesn't do DWIM for reference names, this is *not*\n>> expanded to `refs/heads/git-p4-tmp/6` or something. Previously this\n>> command would have quietly failed to do anything. But after\n>> \"ref_transaction_update(): check refname_is_safe() at a minimum\", `git\n>> update-ref` notices that `git/p4/tmp/6` is not a safe refname (according\n>> to `refname_is_safe()` [2]), and correctly fails with an error message.\n> \n> All errors seem to be related to the Git-P4 branch import. I am no expert\n> in that area because the branch import never worked for me (and I am puzzled\n> to some extend how it is supposed to work given the differences how branches\n> work in Git and P4).\n> \n> This is the offending call:\n> https://github.com/git/git/blob/05219a1276341e72d8082d76b7f5ed394b7437a4/git-p4.py#L3464\n> \n> This is only a cleanup call and we could make all tests work if we remove the\n> cleanup and also the \"cleanup successful check\":\n> https://github.com/git/git/blob/05219a1276341e72d8082d76b7f5ed394b7437a4/t/t9801-git-p4-branch.sh#L303\n> https://github.com/git/git/blob/05219a1276341e72d8082d76b7f5ed394b7437a4/t/t9801-git-p4-branch.sh#L355\n> \n> I am a bit surprised that we do not see other errors given the fact \n> that the branch name is clearly invalid:\n> https://github.com/git/git/blob/05219a1276341e72d8082d76b7f5ed394b7437a4/t/t9803-git-p4-shell-metachars.sh#L102\n> \n> I see two ways to proceed:\n> \n> (1) We remove the cleanup.\n> \n> (2) We sanitize the branch names (e.g. by removing invalid characters).\n> @Michael: Is there a function to \"sanitize\" a given branch name already?\n> \n> Option 1 is trivial and option 2 (my preference) shouldn't be too hard. \n> But maybe Luke has some insights since he added the \"branch with shell char\" \n> test in 52a4880.\n> \n> \n>> Even before this change, Git didn't allow such references to be created\n>> or updated. So I think this test failure is revealing an error in `git\n>> p4 clone` that went undetected before this change.\n>> \n>> Please let me know whether you agree. If so, it is realistic to fix\n>> `git-p4` promptly? This failure is currently blocking\n>> mh/split-under-lock, so if `git-p4` can't be fixed, then I'd have to\n>> either disable t9801 and t9803 in this patch series, or omit the\n>> `refname_is_safe()` check.\n> I am looking into option 2.\n\nAfter looking more into it I realized that the character \"\\$\" in the branch \nname is not even the problem. The git-p4 temp refs are just not located\nunder refs/heads.\n\nThis seems to fix the issue:\n\n--- a/git-p4.py\n+++ b/git-p4.py\n@@ -2274,7 +2274,7 @@ class P4Sync(Command, P4UserMap):\n         self.useClientSpec_from_options = False\n         self.clientSpecDirs = None\n         self.tempBranches = []\n-        self.tempBranchLocation = \"git-p4-tmp\"\n+        self.tempBranchLocation = \"refs/heads/git-p4-tmp\"\n         self.largeFileSystem = None\n \n         if gitConfig('git-p4.largeFileSystem'):\n-- \n\n\n@Luke: Would that be an acceptable solution?\n\nThanks,\nLars\n\n\n> \n>> \n>> In the interest of backwards compatibility, I considered making `git\n>> update-ref -d` continue to fail silently for NOOP operations with unsafe\n>> refnames (one of the requirements being that no old_oid is specified).\n>> But I think that would be giving the wrong signal to scripts that are\n>> doing something that is invalid but pausible, like trying to delete the\n>> reference `../$(basename $PWD)/refs/heads/foo`. Such scripts would be\n>> misled into thinking the deletion was successful. And yet treating\n>> plausibly-sensible requests differently than obviously bogus requests\n>> seems like a path to madness.\n> Agreed!\n> \n> Cheers,\n> Lars\n\n"},{"id":"289633","messageId":"xmqqr3btvyqk.fsf@gitster.mtv.corp.google.com","threadId":"42635","inReplyTo":"57665497.3060100@alum.mit.edu","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-19T18:07:31Z","receivedAt":"2016-06-19T18:08:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n>> Good timing. I was planning to kick split-under-lock and any of its\n>> dependents temporarily out of 'next', so that fixes can choose not\n>> to be incremental, and dependent topics can be rebased on top of the\n>> fixed fondation.  Even if we do incremental, [4] is not sufficient\n>> material for me to write a log message for.\n>> \n>> So people who reviewed what has been in 'next' can revisit [4] and\n>> give review comments, while I could just pick up the history\n>> mentioned there, i.e.\n>> \n>>     git checkout pu\n>>     git pull git://github.com/mhagger/git +split-under-lock:mh/split-under-lock\n>> \n>> and we can start from there?\n>\n> Sure. The branches in my GitHub fork already include all of the\n> improvements and fixes that I know of, and the only outstanding issue is\n> the one that Lars mentioned in this thread (which I believe to be a\n> problem in git-p4).\n>\n> BTW, there are still no conflicts between these branches\n> (split-under-lock, update-ref-errors, ref-iterators, and ref-store) and\n> current master. Therefore, I don't see a need to rebase them onto\n> master. But if you would prefer that I do so, just let me know.\n\nIf the updated split-under-lock itself can build on the same\nupstream commit, then there is no reason to rebase it on top of v2.9\nor anything newer.\n\nYour other topics queued in my tree build on the version of\nsplit-under-lock I have (e.g. mh/ref-store uses ref-iterators and\nsplit-under-lock).  When split-under-lock gets updated, they need to\nbe rebuilt on top of the updated version, and that is what I meant\nby \"dependent topics can be rebased on top\".\n"},{"id":"289635","messageId":"xmqqmvmhvyn5.fsf@gitster.mtv.corp.google.com","threadId":"42635","inReplyTo":"576650E7.70107@alum.mit.edu","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-19T18:09:34Z","receivedAt":"2016-06-19T18:11:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> According to [1], something in that test seems to have been trying to run\n>\n>     git update-ref -d git-p4-tmp/6\n>\n> Similarly in the other failed test.\n\nAh, OK, that would try mucking with .git/git-p4-tmp/6 but that is\nnot a place to have a ref.  It will not participate in reachability\nanalysis and will end up losing the referents.\n\nPerhaps placing it under refs/git-p4-tmp would fix it (both in\ngit-p4 and in tests)?\n"},{"id":"289636","messageId":"xmqqinx5vyg5.fsf@gitster.mtv.corp.google.com","threadId":"42635","inReplyTo":"BC5163B8-7CF2-4106-9FBE-8CCD096252A2@gmail.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-19T18:13:46Z","receivedAt":"2016-06-19T18:13:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider <larsxschneider@gmail.com> writes:\n\n> This seems to fix the issue:\n>\n> --- a/git-p4.py\n> +++ b/git-p4.py\n> @@ -2274,7 +2274,7 @@ class P4Sync(Command, P4UserMap):\n>          self.useClientSpec_from_options = False\n>          self.clientSpecDirs = None\n>          self.tempBranches = []\n> -        self.tempBranchLocation = \"git-p4-tmp\"\n> +        self.tempBranchLocation = \"refs/heads/git-p4-tmp\"\n>          self.largeFileSystem = None\n>  \n>          if gitConfig('git-p4.largeFileSystem'):\n\nAnywhere in refs/ would be OK, but don't you need to adjust the\ntest, too?\n\nEven though I do not use git-p4, I'd imagine that I would be upset\nif temporary refs that are used only during sync contaminated the\nset of local branches I have, if I were a user of git-p4.  Would it\nmake sense to use \"refs/git-p4-tmp\" or something instead?\n\n\n"},{"id":"289638","messageId":"D0F4EDD7-43BB-4311-A8C9-7A83E45CACC6@gmail.com","threadId":"42635","inReplyTo":"xmqqinx5vyg5.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-06-19T18:49:36Z","receivedAt":"2016-06-19T18:49:43Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 19 Jun 2016, at 20:13, Junio C Hamano <gitster@pobox.com> wrote:\n> \n> Lars Schneider <larsxschneider@gmail.com> writes:\n> \n>> This seems to fix the issue:\n>> \n>> --- a/git-p4.py\n>> +++ b/git-p4.py\n>> @@ -2274,7 +2274,7 @@ class P4Sync(Command, P4UserMap):\n>>         self.useClientSpec_from_options = False\n>>         self.clientSpecDirs = None\n>>         self.tempBranches = []\n>> -        self.tempBranchLocation = \"git-p4-tmp\"\n>> +        self.tempBranchLocation = \"refs/heads/git-p4-tmp\"\n>>         self.largeFileSystem = None\n>> \n>>         if gitConfig('git-p4.largeFileSystem'):\n> \n> Anywhere in refs/ would be OK, but don't you need to adjust the\n> test, too?\n> \n> Even though I do not use git-p4, I'd imagine that I would be upset\n> if temporary refs that are used only during sync contaminated the\n> set of local branches I have, if I were a user of git-p4.  Would it\n> make sense to use \"refs/git-p4-tmp\" or something instead?\nYes, \"refs/git-p4-tmp\" would work equally well.\n\n- Lars\n"},{"id":"289639","messageId":"CD2C5DC4-C11B-4D80-8C6F-254DCD30CD02@gmail.com","threadId":"42635","inReplyTo":"D0F4EDD7-43BB-4311-A8C9-7A83E45CACC6@gmail.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-06-19T18:53:59Z","receivedAt":"2016-06-19T18:54:08Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 19 Jun 2016, at 20:49, Lars Schneider <larsxschneider@gmail.com> wrote:\n> \n> \n>> On 19 Jun 2016, at 20:13, Junio C Hamano <gitster@pobox.com> wrote:\n>> \n>> Lars Schneider <larsxschneider@gmail.com> writes:\n>> \n>>> This seems to fix the issue:\n>>> \n>>> --- a/git-p4.py\n>>> +++ b/git-p4.py\n>>> @@ -2274,7 +2274,7 @@ class P4Sync(Command, P4UserMap):\n>>>        self.useClientSpec_from_options = False\n>>>        self.clientSpecDirs = None\n>>>        self.tempBranches = []\n>>> -        self.tempBranchLocation = \"git-p4-tmp\"\n>>> +        self.tempBranchLocation = \"refs/heads/git-p4-tmp\"\n>>>        self.largeFileSystem = None\n>>> \n>>>        if gitConfig('git-p4.largeFileSystem'):\n>> \n>> Anywhere in refs/ would be OK, but don't you need to adjust the\n>> test, too?\n>> \n>> Even though I do not use git-p4, I'd imagine that I would be upset\n>> if temporary refs that are used only during sync contaminated the\n>> set of local branches I have, if I were a user of git-p4.  Would it\n>> make sense to use \"refs/git-p4-tmp\" or something instead?\n> Yes, \"refs/git-p4-tmp\" would work equally well.\n\nPlus, you are right. A minor test adjustment is necessary (although\nthe tests pass without adjustment). I will post a full patch.\n\n- Lars\n"},{"id":"289647","messageId":"xmqqd1ncvisw.fsf@gitster.mtv.corp.google.com","threadId":"42635","inReplyTo":"xmqqmvmhvyn5.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-19T23:51:43Z","receivedAt":"2016-06-19T23:51:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Michael Haggerty <mhagger@alum.mit.edu> writes:\n>\n>> According to [1], something in that test seems to have been trying to run\n>>\n>>     git update-ref -d git-p4-tmp/6\n>>\n>> Similarly in the other failed test.\n>\n> Ah, OK, that would try mucking with .git/git-p4-tmp/6 but that is\n> not a place to have a ref.  It will not participate in reachability\n> analysis and will end up losing the referents.\n>\n> Perhaps placing it under refs/git-p4-tmp would fix it (both in\n> git-p4 and in tests)?\n\nOh, another thing.  If these refs are meant to be transient, they\nare likely to be per worktree, if \"git worktree\" managed multiple\nworktrees that share the same set of branches and tags are in use.\n\nI recall we carved out one hierarchy under refs/ as \"not shared\nacross worktrees\" (was that refs/worktree/ hierarchy?  I didn't\ncheck but please do so when the patch actually is written), and\nthat hierarchy is the appropriate thing to use for this, I think.\n\nThanks.\n"},{"id":"289653","messageId":"18617acb-bcdb-607d-007e-552dabd352cb@web.de","threadId":"42635","inReplyTo":"xmqqk2ho33ig.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2016-06-20T06:06:29Z","receivedAt":"2016-06-20T06:15:09Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"\nThere is a conflict in pu:\n\"jh/clean-smudge-annex\" does not work together with \"tb/convert-peek-in-index\"\n\n(And currently pu didn't compile)\n\n(I will hopefully be able to do a separate review of the smudge/clean patch)\n\n(And joeyh@joeyh.name is not reachable from web.de)\n\n"},{"id":"289660","messageId":"8E05CEA5-C573-4271-A73F-99E7BAE1BF06@gmail.com","threadId":"42635","inReplyTo":"xmqqd1ncvisw.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-06-20T07:57:30Z","receivedAt":"2016-06-20T08:30:10Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 20 Jun 2016, at 01:51, Junio C Hamano <gitster@pobox.com> wrote:\n> \n> Junio C Hamano <gitster@pobox.com> writes:\n> \n>> Michael Haggerty <mhagger@alum.mit.edu> writes:\n>> \n>>> According to [1], something in that test seems to have been trying to run\n>>> \n>>>    git update-ref -d git-p4-tmp/6\n>>> \n>>> Similarly in the other failed test.\n>> \n>> Ah, OK, that would try mucking with .git/git-p4-tmp/6 but that is\n>> not a place to have a ref.  It will not participate in reachability\n>> analysis and will end up losing the referents.\n>> \n>> Perhaps placing it under refs/git-p4-tmp would fix it (both in\n>> git-p4 and in tests)?\n> \n> Oh, another thing.  If these refs are meant to be transient, they\n> are likely to be per worktree, if \"git worktree\" managed multiple\n> worktrees that share the same set of branches and tags are in use.\n> \n> I recall we carved out one hierarchy under refs/ as \"not shared\n> across worktrees\" (was that refs/worktree/ hierarchy?  I didn't\n> check but please do so when the patch actually is written), and\n> that hierarchy is the appropriate thing to use for this, I think.\n\nThanks for the hint. It looks like as if the \"per worktree\" decision\nis made in \"ref.c:466\" \"is_per_worktree_ref\":\nhttps://github.com/git/git/blob/3dc84b0c19932ec9947ca4936b6bfd6421ccb1b4/refs.c#L466-L470\n\nIn ce414b3 \"refs/bisect\" was added to a list of prefixes that are\nper worktree. I could easily add \"refs/git-p4-tmp\" to this list but\nI don't think that would be a good solution. I would prefer to go with \nyour suggestion and add \"refs/worktree\" to the prefix list and then use\n\"refs/worktree/git-p4-tmp\".\n\nLater on we could move \"refs/bisect\" to \"refs/worktree/bisect\" and\nsimplify the \"is_per_worktree_ref\" code, too.\n\nThoughts?\n\nThanks,\nLars"},{"id":"289706","messageId":"xmqq60t3tykh.fsf@gitster.mtv.corp.google.com","threadId":"42635","inReplyTo":"18617acb-bcdb-607d-007e-552dabd352cb@web.de","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-20T20:06:22Z","receivedAt":"2016-06-20T21:00:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen <tboegi@web.de> writes:\n\n> There is a conflict in pu:\n> \"jh/clean-smudge-annex\" does not work together with \"tb/convert-peek-in-index\"\n>\n> (And currently pu didn't compile)\n\nThanks for a report, but didn't I mention this breakage in the\nWhat's cooking report already?\n"},{"id":"289927","messageId":"20160622210958.GA24618@kitenet.net","threadId":"42635","inReplyTo":"18617acb-bcdb-607d-007e-552dabd352cb@web.de","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Joey Hess","fromEmail":"id@joeyh.name","sentAt":"2016-06-22T21:09:58Z","receivedAt":"2016-06-22T21:10:15Z","isPatch":false,"sender":{"key":"id@joeyh.name","avatar":"https://avatars.githubusercontent.com/u/16392?v=4"},"body":"Torsten Bögershausen wrote:\n> There is a conflict in pu:\n> \"jh/clean-smudge-annex\" does not work together with \"tb/convert-peek-in-index\"\n> \n> (And currently pu didn't compile)\n\nI'm sending a v4 of jh/clean-smudge-annex that is rebased on top of\ntb/convert-peek-in-index to fix this.\n\n> (I will hopefully be able to do a separate review of the smudge/clean patch)\n\nWould be appreciated. It'll be 2 weeks until I can work on this any more.\n\n> (And joeyh@joeyh.name is not reachable from web.de)\n\nI'd like to fix whatever's broken; you could send details out of band to\njoeyhess@gmail.com\n\n-- \nsee shy jo\n"},{"id":"289945","messageId":"576B9081.3020405@alum.mit.edu","threadId":"42635","inReplyTo":"8E05CEA5-C573-4271-A73F-99E7BAE1BF06@gmail.com","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2016-06-23T07:32:17Z","receivedAt":"2016-06-23T07:32:27Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/20/2016 09:57 AM, Lars Schneider wrote:\n> \n>> On 20 Jun 2016, at 01:51, Junio C Hamano <gitster@pobox.com> wrote:\n>>\n>> Junio C Hamano <gitster@pobox.com> writes:\n>>\n>>> Michael Haggerty <mhagger@alum.mit.edu> writes:\n>>>\n>>>> According to [1], something in that test seems to have been trying to run\n>>>>\n>>>>    git update-ref -d git-p4-tmp/6\n>>>>\n>>>> Similarly in the other failed test.\n>>>\n>>> Ah, OK, that would try mucking with .git/git-p4-tmp/6 but that is\n>>> not a place to have a ref.  It will not participate in reachability\n>>> analysis and will end up losing the referents.\n>>>\n>>> Perhaps placing it under refs/git-p4-tmp would fix it (both in\n>>> git-p4 and in tests)?\n\nI have to say, I'm still confused about how the old code could have\nworked at all. For quite some time, Git hasn't allowed references with\nweird names like `git-p4-tmp/6` to be created, so how could there be any\nreferences there that need to be deleted? It seems to me that one of the\nfollowing must be true:\n\n* This feature (i.e., whatever needs to create the temporary\n  references) has been broken for a long time, which would imply that\n  there are no tests for it.\n\n* The references are created in some bogus way, like writing files\n  directly to the filesystem, rather than using `git update-ref`.\n  This is broken and will be even more broken soon when we add\n  support for different reference storage backends.\n\n* Such references are never actually created and never actually\n  needed. This would imply that the cleanup code is unnecessary.\n\n* The temporary references are created using `git branch`, and are\n  thus actually named like `refs/heads/git-p4-tmp/6`. In this case\n  the deletion code wasn't cleaning them up right, but the feature\n  might have otherwise worked correctly.\n\n* I'm wrong about Git not allowing references like `git-p4-tmp/6` to\n  be created, in which case I'd like to know what code path allows it\n  so that I can fix it.\n\nAny of these possibilities would mean that your proposed fix is wrong or\nincomplete.\n\n>> Oh, another thing.  If these refs are meant to be transient, they\n>> are likely to be per worktree, if \"git worktree\" managed multiple\n>> worktrees that share the same set of branches and tags are in use.\n>>\n>> I recall we carved out one hierarchy under refs/ as \"not shared\n>> across worktrees\" (was that refs/worktree/ hierarchy?  I didn't\n>> check but please do so when the patch actually is written), and\n>> that hierarchy is the appropriate thing to use for this, I think.\n> \n> Thanks for the hint. It looks like as if the \"per worktree\" decision\n> is made in \"ref.c:466\" \"is_per_worktree_ref\":\n> https://github.com/git/git/blob/3dc84b0c19932ec9947ca4936b6bfd6421ccb1b4/refs.c#L466-L470\n> \n> In ce414b3 \"refs/bisect\" was added to a list of prefixes that are\n> per worktree. I could easily add \"refs/git-p4-tmp\" to this list but\n> I don't think that would be a good solution. I would prefer to go with \n> your suggestion and add \"refs/worktree\" to the prefix list and then use\n> \"refs/worktree/git-p4-tmp\".\n> \n> Later on we could move \"refs/bisect\" to \"refs/worktree/bisect\" and\n> simplify the \"is_per_worktree_ref\" code, too.\n\nThe other part of making `refs/bisect` per-worktree is this horrible\nhack here [1].\n\nI'd like to request that the change for the p4 temprefs be made in two\nsteps:\n\n1. Write references to `refs/git-p4-tmp` or whatever, without\n   worrying about making them per-worktree.\n\n2. Carve out a per-worktree namespace, bikeshed about its name and\n   semantics, make sure it works correctly, then finally move the\n   p4 temporary references and eventually the bisect references there.\n\nThe reason is that step 1 is low-risk, could be made quickly, and is\nenough to unblock mh/split-under-lock and the other patch series that\ndepend on it. Step 2, on the other hand, could take quite a while, and\nits implementation might benefit from changes to reference handling that\nare in the pipeline (e.g., perhaps the horrible hack can be dispensed\nwith). Meanwhile, as far as I understand these references are transient,\nso there are no backwards-compatibility considerations that make\nrenaming them twice more cumbersome than renaming them once.\n\nThanks,\nMichael\n\n[1]\nhttps://github.com/git/git/blob/ab7797dbe95fff38d9265869ea367020046db118/refs/files-backend.c#L176-L192\n\n"},{"id":"289950","messageId":"1f76a4d3-68b1-db33-5c7b-dc5ab104a3ef@web.de","threadId":"42635","inReplyTo":"20160622210958.GA24618@kitenet.net","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2016-06-23T13:13:39Z","receivedAt":"2016-06-23T13:13:59Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"\n\nOn 22/06/16 23:09, Joey Hess wrote:\n> Torsten Bögershausen wrote:\n>> There is a conflict in pu:\n>> \"jh/clean-smudge-annex\" does not work together with \"tb/convert-peek-in-index\"\n>>\n>> (And currently pu didn't compile)\n> I'm sending a v4 of jh/clean-smudge-annex that is rebased on top of\n> tb/convert-peek-in-index to fix this.\n>\n>> (I will hopefully be able to do a separate review of the smudge/clean patch)\n> Would be appreciated. It'll be 2 weeks until I can work on this any more.\n>\n>> (And joeyh@joeyh.name is not reachable from web.de)\n> I'd like to fix whatever's broken; you could send details out of band to\n> joeyhess@gmail.com\n>\nCurrently there is one comment:\nThe (new) usage of assert() in sha1_file.c:\n   assert(would_convert_to_git_filter_fd(path));\n\nThe thing is that we need to check the file system to find .gitatttibutes,\neven if we just did it 1 nanosecond ago.\n\nSo the .gitattributes is done 3 times:\n-1 would_convert_to_git_filter_fd(\n-2 assert(would_convert_to_git_filter_fd(path));\n-3 convert.c/convert_to_git_filter_fd()\n\nThe only situation where this could be useful is when the .gitattributes\nchange between -1 and -2,\nbut then they would have changed between -1 and -3, and convert.c\nwill die().\n\nDoes it make sense to remove -2 ?\n\n\n"},{"id":"290223","messageId":"7DB6E8A8-964F-46B2-B22C-4C70943A7C94@gmail.com","threadId":"42635","inReplyTo":"576B9081.3020405@alum.mit.edu","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2016-06-27T07:09:49Z","receivedAt":"2016-06-27T07:09:58Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 23 Jun 2016, at 09:32, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> \n> On 06/20/2016 09:57 AM, Lars Schneider wrote:\n>> \n>>> On 20 Jun 2016, at 01:51, Junio C Hamano <gitster@pobox.com> wrote:\n>>> \n>>> Junio C Hamano <gitster@pobox.com> writes:\n>>> \n>>>> Michael Haggerty <mhagger@alum.mit.edu> writes:\n>>>> \n>>>>> According to [1], something in that test seems to have been trying to run\n>>>>> \n>>>>>   git update-ref -d git-p4-tmp/6\n>>>>> \n>>>>> Similarly in the other failed test.\n>>>> \n>>>> Ah, OK, that would try mucking with .git/git-p4-tmp/6 but that is\n>>>> not a place to have a ref.  It will not participate in reachability\n>>>> analysis and will end up losing the referents.\n>>>> \n>>>> Perhaps placing it under refs/git-p4-tmp would fix it (both in\n>>>> git-p4 and in tests)?\n> \n> I have to say, I'm still confused about how the old code could have\n> worked at all. For quite some time, Git hasn't allowed references with\n> weird names like `git-p4-tmp/6` to be created, so how could there be any\n> references there that need to be deleted? It seems to me that one of the\n> following must be true:\n> \n> * This feature (i.e., whatever needs to create the temporary\n>  references) has been broken for a long time, which would imply that\n>  there are no tests for it.\n> \n> * The references are created in some bogus way, like writing files\n>  directly to the filesystem, rather than using `git update-ref`.\n>  This is broken and will be even more broken soon when we add\n>  support for different reference storage backends.\n> \n> * Such references are never actually created and never actually\n>  needed. This would imply that the cleanup code is unnecessary.\n> \n> * The temporary references are created using `git branch`, and are\n>  thus actually named like `refs/heads/git-p4-tmp/6`. In this case\n>  the deletion code wasn't cleaning them up right, but the feature\n>  might have otherwise worked correctly.\n> \n> * I'm wrong about Git not allowing references like `git-p4-tmp/6` to\n>  be created, in which case I'd like to know what code path allows it\n>  so that I can fix it.\n> \n> Any of these possibilities would mean that your proposed fix is wrong or\n> incomplete.\n\nAlthough I know git-p4 quite well, I am certainly no expert for the git-p4\nbranch import. I also pointed out in my previous reply ($gmane/297703)\nthat the git-p4 branch import never worked successfully for me. I always\nthought the reason is that my P4 branch history is a bit messy. The clean \ngit-p4 branch test cases work fine, though.\n\n\n>>> Oh, another thing.  If these refs are meant to be transient, they\n>>> are likely to be per worktree, if \"git worktree\" managed multiple\n>>> worktrees that share the same set of branches and tags are in use.\n>>> \n>>> I recall we carved out one hierarchy under refs/ as \"not shared\n>>> across worktrees\" (was that refs/worktree/ hierarchy?  I didn't\n>>> check but please do so when the patch actually is written), and\n>>> that hierarchy is the appropriate thing to use for this, I think.\n>> \n>> Thanks for the hint. It looks like as if the \"per worktree\" decision\n>> is made in \"ref.c:466\" \"is_per_worktree_ref\":\n>> https://github.com/git/git/blob/3dc84b0c19932ec9947ca4936b6bfd6421ccb1b4/refs.c#L466-L470\n>> \n>> In ce414b3 \"refs/bisect\" was added to a list of prefixes that are\n>> per worktree. I could easily add \"refs/git-p4-tmp\" to this list but\n>> I don't think that would be a good solution. I would prefer to go with \n>> your suggestion and add \"refs/worktree\" to the prefix list and then use\n>> \"refs/worktree/git-p4-tmp\".\n>> \n>> Later on we could move \"refs/bisect\" to \"refs/worktree/bisect\" and\n>> simplify the \"is_per_worktree_ref\" code, too.\n> \n> The other part of making `refs/bisect` per-worktree is this horrible\n> hack here [1].\nThanks for the pointer!\n\n\n> I'd like to request that the change for the p4 temprefs be made in two\n> steps:\n> \n> 1. Write references to `refs/git-p4-tmp` or whatever, without\n>   worrying about making them per-worktree.\n> \n> 2. Carve out a per-worktree namespace, bikeshed about its name and\n>   semantics, make sure it works correctly, then finally move the\n>   p4 temporary references and eventually the bisect references there.\n> \n> The reason is that step 1 is low-risk, could be made quickly, and is\n> enough to unblock mh/split-under-lock and the other patch series that\n> depend on it. Step 2, on the other hand, could take quite a while, and\n> its implementation might benefit from changes to reference handling that\n> are in the pipeline (e.g., perhaps the horrible hack can be dispensed\n> with). Meanwhile, as far as I understand these references are transient,\n> so there are no backwards-compatibility considerations that make\n> renaming them twice more cumbersome than renaming them once.\nAgreed! I will post the patch in a few seconds.\n\nCheers,\nLars\n\n\n> \n> Thanks,\n> Michael\n> \n> [1]\n> https://github.com/git/git/blob/ab7797dbe95fff38d9265869ea367020046db118/refs/files-backend.c#L176-L192\n\n"},{"id":"290250","messageId":"xmqqinwubnnp.fsf@gitster.mtv.corp.google.com","threadId":"42635","inReplyTo":"576B9081.3020405@alum.mit.edu","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-27T16:29:46Z","receivedAt":"2016-06-27T16:29:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> I'd like to request that the change for the p4 temprefs be made in two\n> steps:\n>\n> 1. Write references to `refs/git-p4-tmp` or whatever, without\n>    worrying about making them per-worktree.\n>\n> 2. Carve out a per-worktree namespace, bikeshed about its name and\n>    semantics, make sure it works correctly, then finally move the\n>    p4 temporary references and eventually the bisect references there.\n\nHasn't 2. already happened long time ago?  I thought that the\ndirection was that bisect will have to be grandfathered to stay\nthere, and new things would hang beneath a single per-worktree\nhierarchy.\n\nI would have expected that your 1. would be a request to use\nrefs/worktrees/git-p4-tmp.\n\n... goes and looks ...\n\nAhh, I did misremember the discussions.\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/276628\nhttp://thread.gmane.org/gmane.comp.version-control.git/276960/focus=276963\n\nIt appears that in the latter, a more generic refs/worktrees/ was\nsomehow postponed, and only bisect was made per-worktree to fix the\nimmediate breakage.\n\n> The reason is that step 1 is low-risk, could be made quickly, and is\n> enough to unblock mh/split-under-lock and the other patch series that\n> depend on it. Step 2, on the other hand, could take quite a while, and\n> its implementation might benefit from changes to reference handling that\n> are in the pipeline (e.g., perhaps the horrible hack can be dispensed\n> with). Meanwhile, as far as I understand these references are transient,\n> so there are no backwards-compatibility considerations that make\n> renaming them twice more cumbersome than renaming them once.\n"},{"id":"290355","messageId":"5772421F.3030100@alum.mit.edu","threadId":"42635","inReplyTo":"576B9081.3020405@alum.mit.edu","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2016-06-28T09:23:43Z","receivedAt":"2016-06-28T09:24:09Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 06/23/2016 09:32 AM, Michael Haggerty wrote:\n> [...]\n> I have to say, I'm still confused about how the old code could have\n> worked at all. For quite some time, Git hasn't allowed references with\n> weird names like `git-p4-tmp/6` to be created, so how could there be any\n> references there that need to be deleted? It seems to me that one of the\n> following must be true:\n> [...]\n> * I'm wrong about Git not allowing references like `git-p4-tmp/6` to\n>   be created, in which case I'd like to know what code path allows it\n>   so that I can fix it.\n\nI was indeed wrong.\n\nReference names are vetted by `check_refname_format()` on creation, but\nthat function knows and enforces nothing about the `refs/` namespace or\nthe ALL_CAPS convention for top-level references. Moreover, the relevant\ncaller passes the `REFNAME_ALLOW_ONELEVEL` option, which has semantics\nthat are fairly useless as far as I can tell. A casual reader might\nassume that `REFNAME_ALLOW_ONELEVEL` allows one-level reference only if\nthey satisfy the special `ALL_CAPS` convention, but in fact it doesn't\nenforce the convention. (I suppose that `REFNAME_ALLOW_ONELEVEL` was\nmeant for checking partial reference names, for example to vet \"foo\"\nthat the caller wants to pass to `git branch`, which automatically turns\nit into `refs/heads/foo`.)\n\nIn summary, `check_refname_format()` is in some ways less strict than\n`refname_is_safe()`. For example, it allows reference names like\n`git-p4-tmp/6` or even `git-p4-tmp`. With current master:\n\n    $ git update-ref git-p4-tmp HEAD\n    $ echo $?\n    0\n    $ git rev-parse git-p4-tmp\n    cf4c2cfe52be5bd973a4838f73a35d3959ce2f43\n    $ git update-ref -d git-p4-tmp\n    $ echo $?\n    0\n\nI don't know what I was thinking. Long ago, when I refactored and\ndocumented check_refname_format(), I realized that the checks are\nsurprisingly lax and that the `REFNAME_ALLOW_ONELEVEL` option is\nmisleading. But I was new to the project and wasn't brave or energetic\nenough to do something about it. Meanwhile I guess I forgot that it\nnever got fixed. Commit\n\nd0f810f0 2014-09-03 refs.c: allow listing and deleting badly named refs\n\n, which introduced `refname_is_safe()`, perhaps muddled the situation by\nadding a \"fallback\" check that is not strictly laxer than the main check.\n\nWhere does that leave us?\n\n* It is currently possible to create and delete references with\n  names that are neither within `refs/` nor ALL_CAPS (though not\n  remotely).\n\n* Such references do not participate in reachability checks, so\n  they have to be considered semi-broken.\n\n* Users could create chaos (though not remotely) by creating a\n  loose \"reference\" whose name coincides with that of another\n  file under `$GIT_DIR`.\n  (`git update-ref objects/info/alternates HEAD` anyone?)\n\n* `git-p4` is apparently the only code within the Git project that\n  was making use of this questionable freedom.\n\n* Presumably there is user code in the wild that creates and uses\n  such references.\n\nI think we need to get this under control, but given that we've allowed\nsuch references (albeit partly broken) for a long time, we probably need\nto provide an escape hatch to aid the transition. I'm skeptical that the\nmh/split-under-lock patch series is the best place to start such a\ncampaign. On the other hand, I don't want that patch series to open up\nany new avenues to creating references that escape `$GIT_DIR`.\n\nLet me think for a bit about the next step. Input is welcome.\n\nIn any case, I think that Lars's patch to `git-p4` is a good thing.\n\nMichael\n\n"},{"id":"290400","messageId":"xmqq1t3h9pjb.fsf@gitster.mtv.corp.google.com","threadId":"42635","inReplyTo":"5772421F.3030100@alum.mit.edu","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-28T17:44:24Z","receivedAt":"2016-06-28T17:45:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> (I suppose that `REFNAME_ALLOW_ONELEVEL` was\n> meant for checking partial reference names, for example to vet \"foo\"\n> that the caller wants to pass to `git branch`, which automatically turns\n> it into `refs/heads/foo`.)\n\nCorrect.\n\n> In summary, `check_refname_format()` is in some ways less strict than\n> `refname_is_safe()`. For example, it allows reference names like\n> `git-p4-tmp/6` or even `git-p4-tmp`.\n\nAgain, correct.\n\n> I don't know what I was thinking. Long ago, when I refactored and\n> documented check_refname_format(), I realized that the checks are\n> surprisingly lax and that the `REFNAME_ALLOW_ONELEVEL` option is\n> misleading. But I was new to the project and wasn't brave or energetic\n> enough to do something about it. Meanwhile I guess I forgot that it\n> never got fixed. Commit\n>\n> d0f810f0 2014-09-03 refs.c: allow listing and deleting badly named refs\n>\n> , which introduced `refname_is_safe()`, perhaps muddled the situation by\n> adding a \"fallback\" check that is not strictly laxer than the main check.\n>\n> Where does that leave us?\n>\n> * It is currently possible to create and delete references with\n>   names that are neither within `refs/` nor ALL_CAPS (though not\n>   remotely).\n>\n> * Such references do not participate in reachability checks, so\n>   they have to be considered semi-broken.\n>\n> * Users could create chaos (though not remotely) by creating a\n>   loose \"reference\" whose name coincides with that of another\n>   file under `$GIT_DIR`.\n>   (`git update-ref objects/info/alternates HEAD` anyone?)\n\nAll correct.\n\n> * `git-p4` is apparently the only code within the Git project that\n>   was making use of this questionable freedom.\n\nTrue.\n\n> * Presumably there is user code in the wild that creates and uses\n>   such references.\n\nI doubt it, if they value their data.  .git/p4-tmp or .git/p4-tmp/6\nare not just \"partly broken\"--they are just as transient as things\nlike MERGE_HEAD in that the objects pointed by them are subject to\nbe pruned.\n\n> I think we need to get this under control, but given that we've allowed\n> such references (albeit partly broken) for a long time, we probably need\n> to provide an escape hatch to aid the transition. I'm skeptical that the\n> mh/split-under-lock patch series is the best place to start such a\n> campaign. On the other hand, I don't want that patch series to open up\n> any new avenues to creating references that escape `$GIT_DIR`.\n>\n> Let me think for a bit about the next step. Input is welcome.\n>\n> In any case, I think that Lars's patch to `git-p4` is a good thing.\n\nThanks.\n"},{"id":"291311","messageId":"20160712222054.GA10128@kitenet.net","threadId":"42635","inReplyTo":"1f76a4d3-68b1-db33-5c7b-dc5ab104a3ef@web.de","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Joey Hess","fromEmail":"id@joeyh.name","sentAt":"2016-07-12T22:20:54Z","receivedAt":"2016-07-12T22:23:26Z","isPatch":false,"sender":{"key":"id@joeyh.name","avatar":"https://avatars.githubusercontent.com/u/16392?v=4"},"body":"Torsten Bögershausen wrote re jh/clean-smudge-annex:\n> The thing is that we need to check the file system to find .gitatttibutes,\n> even if we just did it 1 nanosecond ago.\n> \n> So the .gitattributes is done 3 times:\n> -1 would_convert_to_git_filter_fd(\n> -2 assert(would_convert_to_git_filter_fd(path));\n> -3 convert.c/convert_to_git_filter_fd()\n> \n> The only situation where this could be useful is when the .gitattributes\n> change between -1 and -2,\n> but then they would have changed between -1 and -3, and convert.c\n> will die().\n> \n> Does it make sense to remove -2 ?\n\nThere's less redundant work going on than at first seems, because \n.gitattribute files are only read once and cached. Verified by strace.\n\nSo, the redundant work is only in the processing that convert_attrs() does\nof the cached .gitattributes.\n\nNotice that there was a similar redundant triple call to convert_attrs()\nbefore my patch set:\n\n1. index_fd checks would_convert_to_git_filter_fd\n2. index_stream_convert_blob does assert(would_convert_to_git_filter_fd(path))\n   (Again redundantly since 1. is its only caller and has already\n   checked.)\n3. in convert_to_git_filter_fd\n\nIf convert_attrs() is somehow expensive, it might be worth passing a\nstruct conv_attrs * into the functions that currently call\nconvert_attrs(). But it does not look expensive to me.\n\nI think it would be safe enough to remove both asserts, at least as the\ncode is structured now.\n\n-- \nsee shy jo\n"},{"id":"291399","messageId":"af41e13f-0320-2e55-a6ac-3fdb46f0bb35@web.de","threadId":"42635","inReplyTo":"20160712222054.GA10128@kitenet.net","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2016-07-14T02:09:02Z","receivedAt":"2016-07-14T02:09:47Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"\n\nOn 07/13/2016 12:20 AM, Joey Hess wrote:\n> Torsten Bögershausen wrote re jh/clean-smudge-annex:\n>> The thing is that we need to check the file system to find .gitatttibutes,\n>> even if we just did it 1 nanosecond ago.\n>>\n>> So the .gitattributes is done 3 times:\n>> -1 would_convert_to_git_filter_fd(\n>> -2 assert(would_convert_to_git_filter_fd(path));\n>> -3 convert.c/convert_to_git_filter_fd()\n>>\n>> The only situation where this could be useful is when the .gitattributes\n>> change between -1 and -2,\n>> but then they would have changed between -1 and -3, and convert.c\n>> will die().\n>>\n>> Does it make sense to remove -2 ?\n>\n> There's less redundant work going on than at first seems, because\n> .gitattribute files are only read once and cached. Verified by strace.\n>\nOK, I think I missed that work (not enough time for Git at the moment)\nJunio, please help me out, do we have a cache here now?\nI tried to figure out that following your attr branch, but failed.\n> So, the redundant work is only in the processing that convert_attrs() does\n> of the cached .gitattributes.\n>\n> Notice that there was a similar redundant triple call to convert_attrs()\n> before my patch set:\n>\n> 1. index_fd checks would_convert_to_git_filter_fd\n> 2. index_stream_convert_blob does assert(would_convert_to_git_filter_fd(path))\n>    (Again redundantly since 1. is its only caller and has already\n>    checked.)\n> 3. in convert_to_git_filter_fd\n>\n> If convert_attrs() is somehow expensive, it might be worth passing a\n> struct conv_attrs * into the functions that currently call\n> convert_attrs(). But it does not look expensive to me.\nI have that on the list, but seems to be uneccesary now.\n>\n> I think it would be safe enough to remove both asserts, at least as the\n> code is structured now.\n>\nOK.\n"},{"id":"291448","messageId":"xmqqtwfsqe2f.fsf@gitster.mtv.corp.google.com","threadId":"42635","inReplyTo":"af41e13f-0320-2e55-a6ac-3fdb46f0bb35@web.de","subject":"Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-14T18:17:44Z","receivedAt":"2016-07-14T18:17:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen <tboegi@web.de> writes:\n\n>> There's less redundant work going on than at first seems, because\n>> .gitattribute files are only read once and cached. Verified by strace.\n>>\n> OK, I think I missed that work (not enough time for Git at the moment)\n> Junio, please help me out, do we have a cache here now?\n\nThe call convert_attrs() makes to the attribute subsystem is:\n\n    git_check_attr(path, NUM_CONV_ATTRS, ccheck)\n\nConceptually, this call has to do the following, and for the very\nfirst call that is actually what it does:\n\n 1. Read all the relevant attrubutes files.  If you are asking for\n    \"a/x/1\", we need to read $GIT_DIR/info/attributes,\n    \".gitattributes\", \"a/.gitattributes\" and \"a/x/.gitattributes\".\n\n 2. Find matching patterns that cover \"a/x/1\", and pick up the\n    attribute definition from the above.\n\nIf you have asked for \"a/x/1\", it is very likely that you would next\nask for \"a/x/2\" (think: \"git checkout a/x\"), and we can realize that\nexactly the same set of attributes files apply to that path.  So an\nobvious optimization is to cache the result of the first step.\n\nIn addition, it is also likely that you would later ask for \"a/y/3\"\nbefore asking for \"b/z/4\" (think: \"git add .\").  A part of the step\n1. that was done when you asked for \"a/x/1\" and then was reused when\nyou asked for \"a/x/2\" can further be reused for this request, by\ndiscarding only what was read from \"a/x/.gitattributes\" and reading\nonly from \"a/y/.gitattributes\".\n\nThe above two optimizations are done in prepare_attr_stack().\n\nUnfortunately this is one of the three reasons why the attribute\nsubsystem is not thread-ready.  I.e. there is only one global cache,\nso if you spawn two threads to speed up \"git add .\" by handing paths\n[a-m]* to one and [n-z]* to the other, they would thrash the cache\nand making it ineffective (even if we protect the cache with mutex,\nwhich obviously has not been done).\n\nI earlier started looking into this, but the effort stalled.  But\nfor a single-thread use, the attributes read from the filesystem are\ncached, and the cache is designed to perform well as long as you\nmake requests in-order.\n\nTo make the attribute look-up thread-ready, the attribute cache\nneeds to become per-thread.\n\nOrthogonal of the threading issue, there is another posssible\noptimization that is not there yet.  The cache can be tied to what\nis in ccheck[] to further reduce the size of the cache, making step\n2. a lot cheaper.  Currently in step 1. we read and keep everything,\nbut if we tie the cache to the contents of ccheck[], we can read and\nignore entries we read in step 1. that does not talk about the\nattributes ccheck[] is interested in.  My plan is to either\n\n (1) make the cache per-thread, limit the reading done in 1. to\n     ccheck[], but invalidate the cache when a different set of\n     attributes are asked; or\n\n (2) make the cache per <thread, ccheck[]>.\n"}]}