{"thread":{"id":"35389","subject":"What's cooking in git.git (Nov 2013, #05; Thu, 21)","startedAt":"2013-11-22T00:19:43Z","lastAt":"2013-11-25T16:17:31Z","messageCount":15,"participants":["Junio C Hamano","Jeff King","Thomas Rast","Vicent Marti","Vicent Martí","Antoine Pelisse"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"230928","messageId":"xmqqtxf51e5c.fsf@gitster.dls.corp.google.com","threadId":"35389","inReplyTo":null,"subject":"What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-11-22T00:19:43Z","receivedAt":"2013-11-22T00:19:43Z","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'.\n\nHopefully 1.8.5-rc3 that was tagged on Wednesday will be the final\nrelease candidate for this cycle.\n\nYou can find the changes described here in the integration branches\nof the repositories listed at\n\n    http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* nd/liteal-pathspecs (2013-10-28) 1 commit\n  (merged to 'next' on 2013-11-01 at 1a91775)\n + pathspec: stop --*-pathspecs impact on internal parse_pathspec() uses\n\n Fixes a regression on 'master' since v1.8.4.\n\n--------------------------------------------------\n[New Topics]\n\n* jj/doc-markup-hints-in-coding-guidelines (2013-11-18) 1 commit\n  (merged to 'next' on 2013-11-21 at 9c638a6)\n + State correct usage of literal examples in man pages in the coding standards\n\n Can wait in 'next'.\n\n\n* jn/perl-lib-extra (2013-11-18) 2 commits\n  (merged to 'next' on 2013-11-20 at 8c90afae)\n + Makefile: add PERLLIB_EXTRA variable that adds to default perl path\n + Makefile: rebuild perl scripts when perl paths change\n\n\n* jj/doc-markup-gitcli (2013-11-20) 1 commit\n  (merged to 'next' on 2013-11-21 at 5e49fa8)\n + Documentation/gitcli.txt: fix double quotes\n\n Can wait in 'next'.\n\n\n* jk/remove-experimental-loose-object-support (2013-11-21) 1 commit\n  (merged to 'next' on 2013-11-21 at d37bab7)\n + drop support for \"experimental\" loose objects\n\n Can wait in 'next'.\n\n\n* jl/commit-v-strip-marker (2013-11-19) 1 commit\n - commit -v: strip diffs and submodule shortlogs from the commit message\n\n Perhaps another reroll for core.commentChar coming?\n\n\n* nd/glossary-content-pathspec-markup (2013-11-21) 1 commit\n  (merged to 'next' on 2013-11-21 at 6072636)\n + glossary-content.txt: fix documentation of \"**\" patterns\n\n Can wait in 'next'.\n\n\n* nd/magic-pathspec (2013-11-20) 1 commit\n  (merged to 'next' on 2013-11-21 at f914a30)\n + diff: restrict pathspec limitations to diff b/f case only\n\n Can wait in 'next'.\n\n--------------------------------------------------\n[Stalled]\n\n* fc/transport-helper-fixes (2013-11-13) 12 commits\n - remote-bzr: support the new 'force' option\n - transport-helper: add support to delete branches\n - fast-export: add support to delete refs\n - fast-import: add support to delete refs\n - transport-helper: add support for old:new refspec\n - fast-export: add new --refspec option\n - fast-export: improve argument parsing\n - test-hg.sh: tests are now expected to pass\n - transport-helper: check for 'forced update' message\n - transport-helper: add 'force' to 'export' helpers\n - transport-helper: don't update refs in dry-run\n - transport-helper: mismerge fix\n\n Updates transport-helper, fast-import and fast-export to allow the\n ref mapping and ref deletion in a way similar to the natively\n supported transports.\n\n The option name \"--refspec\" needs to be rethought. It does not mean\n what refspec usually means, even though it shares the same syntax\n with refspec; calling it --refspec only because it shares the same\n syntax is like calling it --asciistring and does not make sense.\n\n\n* nv/commit-gpgsign-config (2013-11-06) 1 commit\n - Add the commit.gpgsign option to sign all commits\n\n Introduce commit.gpgsign configuration variable to force every\n commit to be GPG signed.\n\n Needs tests, perhaps?\n\n\n* tb/clone-ssh-with-colon-for-port (2013-11-04) 1 commit\n . git clone: is an URL local or ssh\n\n Still being reworked.\n\n\n* cn/thin-push-capability (2013-11-06) 2 commits\n - send-pack: only send a thin pack if the server supports it\n - receive-pack: advertise thin-pack\n\n Peff had a good suggestion to control this by expressing what the\n receiving end wants in a more direct way, namely to advertise a\n 'no-thin' trait in the capability list, which seems to be favored\n by Shawn, too.\n\n\n* jt/commit-fixes-footer (2013-10-30) 1 commit\n - commit: Add -f, --fixes <commit> option to add Fixes: line\n\n There is an ongoing discussion around this topic; in general I am\n fairly negative on a new feature that is too narrow and prefer a\n more generic solution that can be tailored for specific needs, as\n many people stated in the thread.\n\n It appears that the discussion stalled.\n\n\n* np/pack-v4 (2013-09-18) 90 commits\n . packv4-parse.c: add tree offset caching\n . t1050: replace one instance of show-index with verify-pack\n . index-pack, pack-objects: allow creating .idx v2 with .pack v4\n . unpack-objects: decode v4 trees\n . unpack-objects: allow to save processed bytes to a buffer\n - ...\n\n Nico and Duy advancing the eternal vaporware pack-v4.  This is here\n primarily for wider distribution of the preview edition.\n\n Temporarily ejected from 'pu', to try out jk/pack-bitmap, which\n this topic conflicts with.\n\n\n* jk/pack-bitmap (2013-11-18) 22 commits\n - compat/mingw.h: Fix the MinGW and msvc builds\n - pack-bitmap: implement optional name_hash cache\n - t/perf: add tests for pack bitmaps\n - t: add basic bitmap functionality tests\n - count-objects: recognize .bitmap in garbage-checking\n - repack: consider bitmaps when performing repacks\n - repack: handle optional files created by pack-objects\n - repack: turn exts array into array-of-struct\n - repack: stop using magic number for ARRAY_SIZE(exts)\n - pack-objects: implement bitmap writing\n - rev-list: add bitmap mode to speed up object lists\n - pack-objects: use bitmaps when packing objects\n - pack-bitmap: add support for bitmap indexes\n - documentation: add documentation for the bitmap format\n - ewah: compressed bitmap implementation\n - compat: add endianness helpers\n - sha1_file: export `git_open_noatime`\n - revision: allow setting custom limiter function\n - pack-objects: factor out name_hash\n - pack-objects: refactor the packing list\n - revindex: export new APIs\n - sha1write: make buffer const-correct\n\n Borrows the bitmap index into packfiles from JGit to speed up\n enumeration of objects involved in a commit range without having to\n fully traverse the history.\n\n\n* mf/graph-show-root (2013-10-25) 1 commit\n . graph.c: mark root commit differently\n\n In a repository with multiple-roots, \"log --graph\", especially with\n \"--oneline\", does not give the reader enough visual cue to see\n where one line of history ended and a separate history began.\n\n This is the version that marks the roots 'x' when they would have\n been marked as '*'; Keshav Kini suggested an alternative of giving\n an extra blank line after every root, which I tend to think is a\n better approach to the problem.\n\n\n* tg/perf-lib-test-perf-cleanup (2013-09-19) 2 commits\n - perf-lib: add test_perf_cleanup target\n - perf-lib: split starting the test from the execution\n\n Add test_perf_cleanup shell function to the perf suite, that allows\n the script writers to define a test with a clean-up action.\n\n Holding until needed.\n\n\n* yt/shortened-rename (2013-10-18) 2 commits\n - SQUASH??? style fixes and s/omit/shorten/ where appropriate\n - diff.c: keep arrow(=>) on show_stats()'s shortened filename part to make rename visible\n\n Attempts to give more weight on the fact that a filepair represents\n a rename than showing substring of the actual path when diffstat\n lines are not wide enough.\n\n I am not sure if that is solving a right problem, though.\n\n\n* rv/send-email-cache-generated-mid (2013-08-21) 2 commits\n - git-send-email: Cache generated message-ids, use them when prompting\n - git-send-email: add optional 'choices' parameter to the ask sub\n\n\n* rj/read-default-config-in-show-ref-pack-refs (2013-06-17) 3 commits\n - ### DONTMERGE: needs better explanation on what config they need\n - pack-refs.c: Add missing call to git_config()\n - show-ref.c: Add missing call to git_config()\n\n The changes themselves are probably good, but it is unclear what\n basic setting needs to be read for which exact operation.\n\n Waiting for clarification.\n $gmane/228294\n\n\n* jc/format-patch (2013-04-22) 2 commits\n - format-patch: --inline-single\n - format-patch: rename \"no_inline\" field\n\n A new option to send a single patch to the standard output to be\n appended at the bottom of a message.  I personally have no need for\n this, but it was easy enough to cobble together.  Tests, docs and\n stripping out more MIMEy stuff are left as exercises to interested\n parties.\n\n\n* jk/gitweb-utf8 (2013-04-08) 4 commits\n - gitweb: Fix broken blob action parameters on blob/commitdiff pages\n - gitweb: Don't append ';js=(0|1)' to external links\n - gitweb: Make feed title valid utf8\n - gitweb: Fix utf8 encoding for blob_plain, blobdiff_plain, commitdiff_plain, and patch\n\n Various fixes to gitweb.\n\n Drew Northup volunteered to take a look into this.\n $gmane/226216\n\n\n* jc/show-branch (2013-06-07) 5 commits\n - show-branch: use commit slab to represent bitflags of arbitrary width\n - show-branch.c: remove \"all_mask\"\n - show-branch.c: abstract out \"flags\" operation\n - show-branch.c: lift all_mask/all_revs to a global static\n - show-branch.c: update comment style\n\n Waiting for the final step to lift the hard-limit before sending it out.\n\n--------------------------------------------------\n[Cooking]\n\n* jj/log-doc (2013-11-13) 2 commits\n  (merged to 'next' on 2013-11-21 at cb0ddd2)\n + Documentation/git-log.txt: mark-up fix and minor rephasing\n + Documentation/git-log: update \"--log-size\" description\n\n Mark-up fixes.\n\n Can wait in 'next'.\n\n\n* jc/bundle (2013-11-12) 1 commit\n  (merged to 'next' on 2013-11-21 at 535b046)\n + bundle: use argv-array\n\n Code clean-up.\n\n Can wait in 'next'.\n\n\n* jj/rev-list-options-doc (2013-11-18) 2 commits\n  (merged to 'next' on 2013-11-20 at db975de)\n + Documentation/rev-list-options.txt: fix some grammatical issues and typos\n + Documentation/rev-list-options.txt: fix mark-up\n\n Mark-up and grammo fixes.\n\n Can wait in 'next'.\n\n\n* jk/remove-deprecated (2013-11-12) 4 commits\n  (merged to 'next' on 2013-11-13 at c324792)\n + peek-remote: remove deprecated alias of ls-remote\n + lost-found: remove deprecated command\n + tar-tree: remove deprecated command\n + repo-config: remove deprecated alias for \"git config\"\n\n Will cook in 'next' until a distant future.\n\n\n* mi/typofixes (2013-11-12) 3 commits\n  (merged to 'next' on 2013-11-13 at bb7c2eb)\n + contrib: typofixes\n + Documentation/technical/http-protocol.txt: typofixes\n + typofixes: fix misspelt comments\n\n Can wait in 'next'.\n\n\n* rh/remote-hg-bzr-updates (2013-11-18) 9 commits\n  (merged to 'next' on 2013-11-20 at a36f3c4)\n + remote-bzr, remote-hg: fix email address regular expression\n + test-hg.sh: help user correlate verbose output with email test\n + test-hg.sh: fix duplicate content strings in author tests\n + test-hg.sh: avoid obsolete 'test' syntax\n + test-hg.sh: eliminate 'local' bashism\n + test-bzr.sh, test-hg.sh: prepare for change to push.default=simple\n + test-bzr.sh, test-hg.sh: allow running from any dir\n + test-lib.sh: convert $TEST_DIRECTORY to an absolute path\n + remote-hg: don't decode UTF-8 paths into Unicode objects\n\n Can wait in 'next'.\n\n\n* tr/config-multivalue-lift-max (2013-11-13) 1 commit\n  (merged to 'next' on 2013-11-20 at d18aac9)\n + config: arbitrary number of matches for --unset and --replace-all\n\n Can wait in 'next'.\n\n\n* kb/doc-exclude-directory-semantics (2013-11-07) 1 commit\n  (merged to 'next' on 2013-11-13 at 06e5645)\n + gitignore.txt: clarify recursive nature of excluded directories\n\n Can wait in 'next'.\n\n\n* jc/create-directories-microopt (2013-11-11) 1 commit\n - checkout: most of the time we have good leading directories\n\n Of unknown value until tested on non-Linux platforms (especially\n Windows).\n\n Will hold.\n\n\n* jl/submodule-update-retire-orig-flags (2013-11-11) 1 commit\n  (merged to 'next' on 2013-11-13 at 4b70d15)\n + submodule update: remove unnecessary orig_flags variable\n\n Code clean-up.\n\n Can wait in 'next'.\n\n\n* jn/mediawiki-makefile-updates (2013-11-11) 4 commits\n  (merged to 'next' on 2013-11-13 at 71c8d20)\n + git-remote-mediawiki build: handle DESTDIR/INSTLIBDIR with whitespace\n + git-remote-mediawiki build: make 'install' command configurable\n + git-remote-mediawiki: honor DESTDIR in \"make install\"\n + git-remote-mediawiki: do not remove installed files in \"clean\" target\n\n Build and Installation procedure clean-up.\n\n Can wait in 'next'.\n\n\n* tb/doc-fetch-pack-url (2013-11-11) 1 commit\n  (merged to 'next' on 2013-11-13 at 90d6832)\n + git-fetch-pack uses URLs like git-fetch\n\n Can wait in 'next'.\n\n\n* cc/remote-remove-redundant-postfixcmp (2013-11-06) 2 commits\n  (merged to 'next' on 2013-11-06 at 7b45219)\n + Rename suffixcmp() to has_suffix() and invert its result\n  (merged to 'next' on 2013-11-04 at 6408502)\n + builtin/remote: remove postfixcmp() and use suffixcmp() instead\n\n Minor code clean-up.\n\n Can wait in 'next'.\n\n\n* nd/wt-status-align-i18n (2013-11-06) 1 commit\n  (merged to 'next' on 2013-11-13 at b033aa0)\n + wt-status: take the alignment burden off translators\n\n An attempt to automatically align the names in the \"git status\"\n output, taking the display width of (translated) section labels\n into account.\n\n Can wait in 'next'.\n\n\n* sb/sha1-loose-object-info-check-existence (2013-11-06) 1 commit\n  (merged to 'next' on 2013-11-06 at 1ea5b18)\n + sha1_loose_object_info(): do not return success on missing object\n\n \"git cat-file --batch-check=ok\" did not check the existence of the\n named object.\n\n Will cook in 'next'.\n\n\n* gj/push-more-verbose-advice (2013-11-13) 2 commits\n  (merged to 'next' on 2013-11-21 at df10213)\n + push: switch default from \"matching\" to \"simple\"\n  (merged to 'next' on 2013-11-21 at 4ee3d4a)\n + push: enhance unspecified push default warning\n\n Explain 'simple' and 'matching' in \"git push\" advice message; the\n topmost patch is a rebase of jc/push-2.0-default-to-simple on top\n of it.\n\n Will cook in 'next'.\n\n The first one should be merged to 'master' soon after the next\n cycle opens; the other to replace jc/push-2.0-default-to-simple.\n\n\n* rr/for-each-ref-decoration (2013-11-19) 6 commits\n  (merged to 'next' on 2013-11-21 at ee7b0ed)\n + for-each-ref: avoid color leakage\n + for-each-ref: introduce %(color:...) for color\n + for-each-ref: introduce %(upstream:track[short])\n + for-each-ref: introduce %(HEAD) asterisk marker\n + t6300 (for-each-ref): don't hardcode SHA-1 hexes\n + t6300 (for-each-ref): clearly demarcate setup\n\n Can wait in 'next'.\n\n\n* jk/two-way-merge-corner-case-fix (2013-11-04) 3 commits\n  (merged to 'next' on 2013-11-04 at 79f4fb0)\n + t1005: add test for \"read-tree --reset -u A B\"\n + t1005: reindent\n + unpack-trees: fix \"read-tree -u --reset A B\" with conflicted index\n\n Fix a rather longstanding corner-case bug in twoway \"reset to\n there\" merge, which is most often seen in \"git am --abort\".\n\n Will cook in 'next'.\n\n\n* jc/ref-excludes (2013-11-01) 5 commits\n  (merged to 'next' on 2013-11-04 at fac1ed0)\n + rev-parse: introduce --exclude=<glob> to tame wildcards\n + rev-list --exclude: export add/clear-ref-exclusion and ref-excluded API\n + rev-list --exclude: tests\n + document --exclude option\n + revision: introduce --exclude=<glob> to tame wildcards\n\n People often wished a way to tell \"git log --branches\" (and \"git\n log --remotes --not --branches\") to exclude some local branches\n from the expansion of \"--branches\" (similarly for \"--tags\", \"--all\"\n and \"--glob=<pattern>\").  Now they have one.\n\n Can wait in 'next'.\n\n\n* jk/replace-perl-in-built-scripts (2013-10-29) 1 commit\n  (merged to 'next' on 2013-11-01 at 2384e29)\n + use @@PERL@@ in built scripts\n\n Can wait in 'next'.\n\n\n* jh/loose-object-dirs-creation-race (2013-10-28) 1 commit\n  (merged to 'next' on 2013-11-01 at 3169b0f)\n + sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs\n\n Will cook in 'next'.\n\n\n* th/reflog-annotated-tag (2013-10-28) 1 commit\n  (merged to 'next' on 2013-11-01 at 8b154cc)\n + reflog: handle lightweight and annotated tags equally\n\n \"git log -g $annotated_tag\", when there is no reflog history, should\n have produced a single output entry (i.e. the ref creation event),\n but instead showed the history leading to the tag.\n\n Broken at the design level.  Any reflog entry that points at a non\n commit needs to be handled with new code that does not exist yet,\n and lifting the \"this code handles only commits\" without adding\n such code does not solve anything.\n\n Will discard.\n\n\n* tr/merge-recursive-index-only (2013-10-28) 3 commits\n - merge-recursive: -Xindex-only to leave worktree unchanged\n - merge-recursive: internal flag to avoid touching the worktree\n - merge-recursive: remove dead conditional in update_stages()\n\n Will hold until using script appears.\n\n\n* bc/http-100-continue (2013-10-31) 3 commits\n  (merged to 'next' on 2013-11-01 at e12ae23)\n + remote-curl: fix large pushes with GSSAPI\n + remote-curl: pass curl slot_results back through run_slot\n + http: return curl's AUTHAVAIL via slot_results\n\n Issue \"100 Continue\" responses to help use of GSS-Negotiate\n authentication scheme over HTTP transport when needed.\n\n Will cook in 'next'.\n\n\n* jc/merge-base-reflog (2013-10-29) 2 commits\n  (merged to 'next' on 2013-11-01 at 6114764)\n + merge-base: teach \"--fork-point\" mode\n + merge-base: use OPT_CMDMODE and clarify the command line parsing\n\n Code the logic in \"pull --rebase\" that figures out a fork point\n from reflog entries in C.\n\n Will cook in 'next'.\n\n\n* jk/robustify-parse-commit (2013-10-24) 6 commits\n  (merged to 'next' on 2013-11-01 at 2bfbaab)\n + checkout: do not die when leaving broken detached HEAD\n + use parse_commit_or_die instead of custom message\n + use parse_commit_or_die instead of segfaulting\n + assume parse_commit checks for NULL commit\n + assume parse_commit checks commit->object.parsed\n + log_tree_diff: die when we fail to parse a commit\n\n Will cook in 'next'.\n\n\n* mh/fetch-tags-in-addition-to-normal-refs (2013-10-30) 23 commits\n  (merged to 'next' on 2013-11-06 at 6932893)\n + fetch: improve the error messages emitted for conflicting refspecs\n + handle_duplicate(): mark error message for translation\n + ref_remote_duplicates(): extract a function handle_duplicate()\n + ref_remove_duplicates(): simplify loop logic\n + t5536: new test of refspec conflicts when fetching\n + ref_remove_duplicates(): avoid redundant bisection\n + git-fetch.txt: improve description of tag auto-following\n + fetch-options.txt: simplify ifdef/ifndef/endif usage\n + fetch, remote: properly convey --no-prune options to subprocesses\n + builtin/remote.c:update(): use struct argv_array\n + builtin/remote.c: reorder function definitions\n + query_refspecs(): move some constants out of the loop\n + fetch --prune: prune only based on explicit refspecs\n + fetch --tags: fetch tags *in addition to* other stuff\n + fetch: only opportunistically update references based on command line\n + get_expanded_map(): avoid memory leak\n + get_expanded_map(): add docstring\n + builtin/fetch.c: reorder function definitions\n + get_ref_map(): rename local variables\n + api-remote.txt: correct section \"struct refspec\"\n + t5510: check that \"git fetch --prune --tags\" does not prune branches\n + t5510: prepare test refs more straightforwardly\n + t5510: use the correct tag name in test\n\n The \"-tags\" option to \"git fetch\" used to be literally a synonym to\n a \"refs/tags/*:refs/tags/*\" refspec, which meant that (1) as an\n explicit refspec given from the command line, it silenced the lazy\n \"git fetch\" default that is configured, and (2) also as an explicit\n refspec given from the command line, it interacted with \"--prune\"\n to remove any tag that the remote we are fetching from does not\n have.\n\n This demotes it to an option; with it, we fetch all tags in\n addition to what would be fetched without the option, and it does\n not interact with the decision \"--prune\" makes to see what\n remote-tracking refs the local has are missing the remote\n counterpart.\n\n Will cook in 'next'.\n\n\n* nv/parseopt-opt-arg (2013-10-31) 2 commits\n  (merged to 'next' on 2013-11-01 at cd2afd9)\n + rev-parse --parseopt: add the --stuck-long mode\n + Use the word 'stuck' instead of 'sticked'\n\n Enhance \"rev-parse --parseopt\" mode to help parsing options with\n an optional parameter.\n\n Will cook in 'next'.\n\n\n* ak/submodule-foreach-quoting (2013-09-27) 1 commit\n  (merged to 'next' on 2013-10-14 at d77c5f1)\n + submodule foreach: skip eval for more than one argument\n\n A behavior change, but a worthwhile one: \"git submodule foreach\"\n was treating its arguments as part of a single command to be\n concatenated and passed to a shell, making writing buggy\n scripts too easy.\n\n This patch preserves the old \"just pass it to the shell\" behavior\n when a single argument is passed to 'git submodule foreach' and\n moves to a new \"skip the shell and use the arguments passed\n unmolested\" behavior when more than one argument is passed.\n\n The old behavior (always concatenating and passing to the shell)\n was similar to the 'ssh' command, while the new behavior (switching\n on the number of arguments) is what 'xterm -e' does.\n\n May need more thought to make sure this change is advertised well\n so that scripts that used multiple arguments but added their own\n extra layer of quoting are not broken.\n\n Will cook in 'next'.\n\n\n* kb/fast-hashmap (2013-11-18) 14 commits\n - read-cache.c: fix memory leaks caused by removed cache entries\n - builtin/update-index.c: cleanup update_one\n - fix 'git update-index --verbose --again' output\n - remove old hash.[ch] implementation\n - name-hash.c: remove cache entries instead of marking them CE_UNHASHED\n - name-hash.c: use new hash map implementation for cache entries\n - name-hash.c: remove unreferenced directory entries\n - name-hash.c: use new hash map implementation for directories\n - diffcore-rename.c: use new hash map implementation\n - diffcore-rename.c: simplify finding exact renames\n - diffcore-rename.c: move code around to prepare for the next patch\n - buitin/describe.c: use new hash map implementation\n - add a hashtable implementation that supports O(1) removal\n - submodule: don't access the .gitmodules cache entry after removing it\n\n Improvements to our hash table to get it to meet the needs of the\n msysgit fscache project, with some nice performance improvements.\n\n The preparatory clean-up to submodule from Jens is at the bottom. I\n also squashed in a fix-up by Karsten found at $gmane/236468 (please\n double-check the result).\n\n\n* jn/add-2.0-u-A-sans-pathspec (2013-04-26) 1 commit\n  (merged to 'next' on 2013-10-28 at d8cdf30)\n + git add: -u/-A now affects the entire working tree\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/core-checkstat-2.0 (2013-05-06) 1 commit\n  (merged to 'next' on 2013-10-28 at f1bec96)\n + core.statinfo: remove as promised in Git 2.0\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/push-2.0-default-to-simple (2013-06-18) 1 commit\n  (merged to 'next' on 2013-10-28 at 3153a9e)\n + push: switch default from \"matching\" to \"simple\"\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/add-2.0-ignore-removal (2013-04-22) 1 commit\n  (merged to 'next' on 2013-10-28 at 5fd76ec)\n + git add <pathspec>... defaults to \"-A\"\n\n Updated endgame for \"git add <pathspec>\" that defaults to \"--all\"\n aka \"--no-ignore-removal\".\n\n Will cook in 'next' until Git 2.0.\n\n\n* jc/hold-diff-remove-q-synonym-for-no-deletion (2013-07-19) 1 commit\n  (merged to 'next' on 2013-11-01 at 5fc26e4)\n + diff: remove \"diff-files -q\" in a version of Git in a distant future\n\n Will cook in 'next' until a distant future.\n"},{"id":"230935","messageId":"20131122102345.GC12042@sigill.intra.peff.net","threadId":"35389","inReplyTo":"xmqqtxf51e5c.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-11-22T10:23:45Z","receivedAt":"2013-11-22T10:23:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 21, 2013 at 04:19:43PM -0800, Junio C Hamano wrote:\n\n> * np/pack-v4 (2013-09-18) 90 commits\n>  . packv4-parse.c: add tree offset caching\n>  . t1050: replace one instance of show-index with verify-pack\n>  . index-pack, pack-objects: allow creating .idx v2 with .pack v4\n>  . unpack-objects: decode v4 trees\n>  . unpack-objects: allow to save processed bytes to a buffer\n>  - ...\n> \n>  Nico and Duy advancing the eternal vaporware pack-v4.  This is here\n>  primarily for wider distribution of the preview edition.\n> \n>  Temporarily ejected from 'pu', to try out jk/pack-bitmap, which\n>  this topic conflicts with.\n\nI had a look at the conflicts. Textually, I do not think it is anything\ntoo serious; it is mostly a case of adding unrelated lines in the same\nspot. I am happy to help with resolving that if there is a need.\n\nHowever, there may be semantic conflicts. The big one I can think of is\nhow packfile reuse interacts with various versions. We only do pack\nreuse during a --stdout pack to a client. At this point, that means we\nmust be outputting packv2. If we have packv2 on disk, we are fine. If we\nhave packv4 on disk, I guess we simply need to disable reuse, which\nshould not be hard.\n\nOnce we start sending packv4 to clients, we'll have to reevaluate.\nProbably we can just get away with turning off reuse when there is a\nmismatch, though if my understanding of packv4 is correct, we could\nstill reuse packv2 entries. We can put that off until somebody works on\npackv4-on-the-wire, though. :)\n\n> * jk/pack-bitmap (2013-11-18) 22 commits\n>  - compat/mingw.h: Fix the MinGW and msvc builds\n>  - pack-bitmap: implement optional name_hash cache\n>  - t/perf: add tests for pack bitmaps\n>  - t: add basic bitmap functionality tests\n>  - count-objects: recognize .bitmap in garbage-checking\n>  - repack: consider bitmaps when performing repacks\n>  - repack: handle optional files created by pack-objects\n>  - repack: turn exts array into array-of-struct\n>  - repack: stop using magic number for ARRAY_SIZE(exts)\n>  - pack-objects: implement bitmap writing\n>  - rev-list: add bitmap mode to speed up object lists\n>  - pack-objects: use bitmaps when packing objects\n>  - pack-bitmap: add support for bitmap indexes\n>  - documentation: add documentation for the bitmap format\n>  - ewah: compressed bitmap implementation\n>  - compat: add endianness helpers\n>  - sha1_file: export `git_open_noatime`\n>  - revision: allow setting custom limiter function\n>  - pack-objects: factor out name_hash\n>  - pack-objects: refactor the packing list\n>  - revindex: export new APIs\n>  - sha1write: make buffer const-correct\n> \n>  Borrows the bitmap index into packfiles from JGit to speed up\n>  enumeration of objects involved in a commit range without having to\n>  fully traverse the history.\n\nLooks like you picked up my latest re-roll with Ramsay's fix on top.\nThere wasn't a lot of review on this past round (I'm not surprised; it's\na dauntingly large chunk to review).  I outlined a few possible open\nissues in the cover letter, but I'd be happy to build those on top,\nwhich I think will make review of them a lot easier.\n\nDo we want to try this in 'next' post-1.8.5, or should I try to prod an\narea expert like Shawn into doing another round of review?\n\n-Peff\n"},{"id":"230954","messageId":"87d2lsjs4q.fsf@linux-k42r.v.cablecom.net","threadId":"35389","inReplyTo":"20131122102345.GC12042@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-11-22T16:52:37Z","receivedAt":"2013-11-22T16:52:37Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>> * jk/pack-bitmap (2013-11-18) 22 commits\n[...]\n>>  Borrows the bitmap index into packfiles from JGit to speed up\n>>  enumeration of objects involved in a commit range without having to\n>>  fully traverse the history.\n>\n> Looks like you picked up my latest re-roll with Ramsay's fix on top.\n> There wasn't a lot of review on this past round (I'm not surprised; it's\n> a dauntingly large chunk to review).  I outlined a few possible open\n> issues in the cover letter, but I'd be happy to build those on top,\n> which I think will make review of them a lot easier.\n>\n> Do we want to try this in 'next' post-1.8.5, or should I try to prod an\n> area expert like Shawn into doing another round of review?\n\nHmm, maybe I missed something, but AFAICS you (or Vicent) never acted on\nor responded to my June reviews in this thread:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/228918\n\nand again mentioned here, though I didn't point out all of them:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/236587/focus=236740\n\nGranted, the way I verified this was checking whether you renamed\nrlw_xor_run_bit() to something more fitting, so perhaps you just forgot\nthat one thing but did all the rest.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"230957","messageId":"20131122172626.GA4881@sigill.intra.peff.net","threadId":"35389","inReplyTo":"87d2lsjs4q.fsf@linux-k42r.v.cablecom.net","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-11-22T17:26:27Z","receivedAt":"2013-11-22T17:26:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 22, 2013 at 05:52:37PM +0100, Thomas Rast wrote:\n\n> > Looks like you picked up my latest re-roll with Ramsay's fix on top.\n> > There wasn't a lot of review on this past round (I'm not surprised; it's\n> > a dauntingly large chunk to review).  I outlined a few possible open\n> > issues in the cover letter, but I'd be happy to build those on top,\n> > which I think will make review of them a lot easier.\n> >\n> > Do we want to try this in 'next' post-1.8.5, or should I try to prod an\n> > area expert like Shawn into doing another round of review?\n> \n> Hmm, maybe I missed something, but AFAICS you (or Vicent) never acted on\n> or responded to my June reviews in this thread:\n> \n>   http://thread.gmane.org/gmane.comp.version-control.git/228918\n> \n> and again mentioned here, though I didn't point out all of them:\n> \n>   http://thread.gmane.org/gmane.comp.version-control.git/236587/focus=236740\n\nSorry, I didn't respond directly to the email. Vicent did a pass for\nstyle and documentation shortly after the initial series, and then I did\nanother pass in the most recent re-roll, adding a C fallback for the\ngcc builtin. I thought that covered it, but:\n\n> Granted, the way I verified this was checking whether you renamed\n> rlw_xor_run_bit() to something more fitting, so perhaps you just forgot\n> that one thing but did all the rest.\n\nI didn't touch that. Vicent, did you have a comment on the name (it\nreally does look like it is a negation, and the only caller is\newah_not).\n\n-Peff\n"},{"id":"230961","messageId":"87vbzkiahs.fsf@linux-k42r.v.cablecom.net","threadId":"35389","inReplyTo":"20131122172626.GA4881@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-11-22T17:58:55Z","receivedAt":"2013-11-22T17:58:55Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>> Hmm, maybe I missed something, but AFAICS you (or Vicent) never acted on\n>> or responded to my June reviews in this thread:\n>> \n>>   http://thread.gmane.org/gmane.comp.version-control.git/228918\n[...]\n>> Granted, the way I verified this was checking whether you renamed\n>> rlw_xor_run_bit() to something more fitting, so perhaps you just forgot\n>> that one thing but did all the rest.\n>\n> I didn't touch that. Vicent, did you have a comment on the name (it\n> really does look like it is a negation, and the only caller is\n> ewah_not).\n\nHmm, so it really was that one unlucky thing :-)\n\nI don't have much to say on the area, but if you think it helps you I\ncan set aside some time RSN to review the second half of the series,\ntoo.  Back in June I only looked at the first half.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"230964","messageId":"xmqq61rk1b52.fsf@gitster.dls.corp.google.com","threadId":"35389","inReplyTo":"20131122102345.GC12042@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-11-22T19:36:57Z","receivedAt":"2013-11-22T19:36:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Looks like you picked up my latest re-roll with Ramsay's fix on top.\n> There wasn't a lot of review on this past round (I'm not surprised; it's\n> a dauntingly large chunk to review).  I outlined a few possible open\n> issues in the cover letter, but I'd be happy to build those on top,\n> which I think will make review of them a lot easier.\n>\n> Do we want to try this in 'next' post-1.8.5, or should I try to prod an\n> area expert like Shawn into doing another round of review?\n\nYes ;-).\n\nI recall starting to read the series over and then got sidetracked\nin the middle and never finishing.  I'll try to make time sometime\nthis weekend (we are still buried in boxes after the move, though,\nso no promises) myself.\n\nHow close is this what you guys are running in production these\ndays, by the way?\n"},{"id":"230967","messageId":"CAFFjANQni7mvFBuAqJnPpTJ_68+rJKU6KmdRAWbyK_jbi0S=xA@mail.gmail.com","threadId":"35389","inReplyTo":"20131122172626.GA4881@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Vicent Marti","fromEmail":"vicent@github.com","sentAt":"2013-11-22T19:40:55Z","receivedAt":"2013-11-22T19:40:55Z","isPatch":false,"sender":{"key":"vicent@github.com","avatar":"https://gravatar.com/avatar/9d57a2b1e3137bf84342ac1dfdf1cde409b86e8fda5397d05f40f17fa5b84a63?d=mp&s=160"},"body":"On Fri, Nov 22, 2013 at 6:26 PM, Jeff King <peff@peff.net> wrote:\n>> Granted, the way I verified this was checking whether you renamed\n>> rlw_xor_run_bit() to something more fitting, so perhaps you just forgot\n>> that one thing but did all the rest.\n>\n> I didn't touch that. Vicent, did you have a comment on the name (it\n> really does look like it is a negation, and the only caller is\n> ewah_not).\n\nYes, the name was ported straight from the original library and kept\nas-is to make the translation more straightforward. These sources are\n--again-- a translation, so I tried to remain as close to the original\nJava implementation as possible.\n\nI agree the name is not ideal, but it does make quite a bit of sense.\nIt effectively inverts the word based on the run bit, which is the\nequivalent of xoring it with the bit if it's one.\n\nLove,\nvmg\n"},{"id":"230968","messageId":"CAFFjANQy72zLuxtpA+-nMhYEt=qfOu_FSszR8X7QNPTKBEi6tA@mail.gmail.com","threadId":"35389","inReplyTo":"xmqq61rk1b52.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Vicent Martí","fromEmail":"tanoku@gmail.com","sentAt":"2013-11-22T19:47:25Z","receivedAt":"2013-11-22T19:47:25Z","isPatch":false,"sender":{"key":"tanoku@gmail.com","avatar":"https://gravatar.com/avatar/271386991cb4c2b8f1e1ed1d059f3422cc3485de7a598f65043f70be021d095b?d=mp&s=160"},"body":"On Fri, Nov 22, 2013 at 8:36 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Do we want to try this in 'next' post-1.8.5, or should I try to prod an\n>> area expert like Shawn into doing another round of review?\n>\n> Yes ;-).\n>\n> I recall starting to read the series over and then got sidetracked\n> in the middle and never finishing.  I'll try to make time sometime\n> this weekend (we are still buried in boxes after the move, though,\n> so no promises) myself.\n>\n> How close is this what you guys are running in production these\n> days, by the way?\n\nWe are running a slightly older version of the patchset, because we're\nstill on 1.8.4 and the current reroll doesn't apply cleanly there.\n\nIf this could make it to `next` some time next week, that would work\nout great for us, because we may start considering using `next` as a\npartial or full deployment on our production machines\n\nThis also means that we could exercise the patchset and everything\nelse that is queued up in next release... You must remember all the\ncorner cases and bugs peff brings to the list every time we deploy a\nnew Git to production. Wouldn't it be nice to have a thorough checking\nof the current iteration *before* the release, and not after? :)\n\n*hint hint*\n"},{"id":"230969","messageId":"xmqqr4a8yzga.fsf@gitster.dls.corp.google.com","threadId":"35389","inReplyTo":"CAFFjANQy72zLuxtpA+-nMhYEt=qfOu_FSszR8X7QNPTKBEi6tA@mail.gmail.com","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-11-22T20:05:25Z","receivedAt":"2013-11-22T20:05:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Vicent Martí <tanoku@gmail.com> writes:\n\n> On Fri, Nov 22, 2013 at 8:36 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> We are running a slightly older version of the patchset, because we're\n> still on 1.8.4 and the current reroll doesn't apply cleanly there.\n>\n> If this could make it to `next` some time next week, that would work\n> out great for us, because we may start considering using `next` as a\n> partial or full deployment on our production machines\n\nI do not think potentially incompatible stuff that are slated for\n2.0 that have been cooking in 'next' affects the server side, so\nthat may be a good and safe move.\n\n> This also means that we could exercise the patchset and everything\n> else that is queued up in next release...\n\nThere is no 'next release' though; there is no guarantee what is\ncooking in 'next' will be in any future release ;-).\n\nIn any case, it is nice to see that people from a large hosting site\nfinally taking a hint from my occasional light complaints that come\nafter \"thanks for reporting\" whenever I see regression and breakage\nreport soon after a topic graduates to 'master' ;-).  It is good to\nsee that more people starting to adopt the 'next' branch early for\nwider testing.\n\nThanks.\n"},{"id":"230970","messageId":"87bo1ci44d.fsf@linux-k42r.v.cablecom.net","threadId":"35389","inReplyTo":"CAFFjANQni7mvFBuAqJnPpTJ_68+rJKU6KmdRAWbyK_jbi0S=xA@mail.gmail.com","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-11-22T20:16:34Z","receivedAt":"2013-11-22T20:16:34Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Vicent Marti <vicent@github.com> writes:\n\n> On Fri, Nov 22, 2013 at 6:26 PM, Jeff King <peff@peff.net> wrote:\n>> I didn't touch that. Vicent, did you have a comment on the name (it\n>> really does look like it is a negation, and the only caller is\n>> ewah_not).\n>\n> Yes, the name was ported straight from the original library and kept\n> as-is to make the translation more straightforward. These sources are\n> --again-- a translation, so I tried to remain as close to the original\n> Java implementation as possible.\n>\n> I agree the name is not ideal, but it does make quite a bit of sense.\n> It effectively inverts the word based on the run bit, which is the\n> equivalent of xoring it with the bit if it's one.\n\nIt's a funny xor that doesn't take a second argument ;-)\n\nAnyway, let's not argue forever about the choice of this name.  It's\njust the first thing that came to my mind from the original review, so I\nused it as an indicator to see if you had done something about it.  It\nseems I picked an indicator that is not significant for the overall\nstate.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"230976","messageId":"20131122223222.GA7538@sigill.intra.peff.net","threadId":"35389","inReplyTo":"xmqqr4a8yzga.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-11-22T22:32:22Z","receivedAt":"2013-11-22T22:32:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 22, 2013 at 12:05:25PM -0800, Junio C Hamano wrote:\n\n> > If this could make it to `next` some time next week, that would work\n> > out great for us, because we may start considering using `next` as a\n> > partial or full deployment on our production machines\n> \n> I do not think potentially incompatible stuff that are slated for\n> 2.0 that have been cooking in 'next' affects the server side, so\n> that may be a good and safe move.\n\nI do not think we will literally run `next` in this case, but probably\nv1.8.5 + selected topics (like this one :) ).\n\nWe do not need to base ourselves on a release, of course, and we may\nstart using a rolling version of master, but choose quiescent points in\nthe cycle (like starting with a release, and then rolling forward around\n-rc time). I started trying that with this cycle, which is how I found\nthe --literal-pathspec regression in mid-cycle, and then found out the\nfix hadn't graduated during -rc. :)\n\nIf that proves stable, then I will consider bumping up our frequency of\nfollowing `master`, and then eventually following `next` (possibly with\nsome lag). As a large site, we get to expose the code to a lot of new\npeople; but we also need to be mindful that we are exposing a lot of\npeople to new bugs.\n\n-Peff\n"},{"id":"230977","messageId":"20131122223654.GB7538@sigill.intra.peff.net","threadId":"35389","inReplyTo":"87vbzkiahs.fsf@linux-k42r.v.cablecom.net","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-11-22T22:36:54Z","receivedAt":"2013-11-22T22:36:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 22, 2013 at 06:58:55PM +0100, Thomas Rast wrote:\n\n> > I didn't touch that. Vicent, did you have a comment on the name (it\n> > really does look like it is a negation, and the only caller is\n> > ewah_not).\n> \n> Hmm, so it really was that one unlucky thing :-)\n\nI don't promise there is only one unlucky thing. :) Only that we made a\ngood faith effort to address the comments. There were a lot of comments\nand a lot of re-rolls, and I would not be surprised if something else\nwas missed (I am not thinking of anything in particular, but just\npreparing you mentally).\n\n> I don't have much to say on the area, but if you think it helps you I\n> can set aside some time RSN to review the second half of the series,\n> too.  Back in June I only looked at the first half.\n\nI would love that. My comments to Junio were not to rush the topic, but\nmainly to keep it progressing.\n\nRe-rolling such a big chunk of code _is_ a pain for both me and for\nreviewers, so I wouldn't mind switching to \"fixes on top\" instead of\nre-rolling at some point. But we can do another round or two of re-roll\nfirst.\n\n-Peff\n"},{"id":"230978","messageId":"87vbzkghs9.fsf@linux-k42r.v.cablecom.net","threadId":"35389","inReplyTo":"20131122223654.GB7538@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Thomas Rast","fromEmail":"tr@thomasrast.ch","sentAt":"2013-11-22T23:04:22Z","receivedAt":"2013-11-22T23:04:22Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Re-rolling such a big chunk of code _is_ a pain for both me and for\n> reviewers, so I wouldn't mind switching to \"fixes on top\" instead of\n> re-rolling at some point. But we can do another round or two of re-roll\n> first.\n\nNo, actually I think the plan that you sketched in the other side thread\nsounded nice: give it some exposure in next.  I'll still try and read\nthe rest, but that way it hopefully gets (much) more testing.\n\n-- \nThomas Rast\ntr@thomasrast.ch\n"},{"id":"230988","messageId":"CALWbr2xzY6o6ubuLTBd5VaUSqOS6+Vg7o7WfxbOE=6Fc1ob8bg@mail.gmail.com","threadId":"35389","inReplyTo":"xmqqtxf51e5c.fsf@gitster.dls.corp.google.com","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-11-23T11:25:47Z","receivedAt":"2013-11-23T11:25:47Z","isPatch":false,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"On Fri, Nov 22, 2013 at 1:19 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> * rh/remote-hg-bzr-updates (2013-11-18) 9 commits\n>   (merged to 'next' on 2013-11-20 at a36f3c4)\n>  + remote-bzr, remote-hg: fix email address regular expression\n>  + test-hg.sh: help user correlate verbose output with email test\n>  + test-hg.sh: fix duplicate content strings in author tests\n>  + test-hg.sh: avoid obsolete 'test' syntax\n>  + test-hg.sh: eliminate 'local' bashism\n>  + test-bzr.sh, test-hg.sh: prepare for change to push.default=simple\n>  + test-bzr.sh, test-hg.sh: allow running from any dir\n>  + test-lib.sh: convert $TEST_DIRECTORY to an absolute path\n>  + remote-hg: don't decode UTF-8 paths into Unicode objects\n>\n>  Can wait in 'next'.\n\nWould it be possible to merge the first commit of this series in\nmaster (and eventually in maint) ?\nMy commit (11362653: remote-hg: unquote C-style paths when exporting)\nbreaks the remote-hg tests since v1.8.4.3 (sorry about that), and is\nfixed by this commit. It would be nice to deliver 1.8.5 with working\nremote-helpers tests.\n\nCheers,\nAntoine\n"},{"id":"231074","messageId":"xmqqhab0zc9w.fsf@gitster.dls.corp.google.com","threadId":"35389","inReplyTo":"CALWbr2xzY6o6ubuLTBd5VaUSqOS6+Vg7o7WfxbOE=6Fc1ob8bg@mail.gmail.com","subject":"Re: What's cooking in git.git (Nov 2013, #05; Thu, 21)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-11-25T16:17:31Z","receivedAt":"2013-11-25T16:17:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Antoine Pelisse <apelisse@gmail.com> writes:\n\n> On Fri, Nov 22, 2013 at 1:19 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> * rh/remote-hg-bzr-updates (2013-11-18) 9 commits\n>>   (merged to 'next' on 2013-11-20 at a36f3c4)\n>>  + remote-bzr, remote-hg: fix email address regular expression\n>>  + test-hg.sh: help user correlate verbose output with email test\n>>  + test-hg.sh: fix duplicate content strings in author tests\n>>  + test-hg.sh: avoid obsolete 'test' syntax\n>>  + test-hg.sh: eliminate 'local' bashism\n>>  + test-bzr.sh, test-hg.sh: prepare for change to push.default=simple\n>>  + test-bzr.sh, test-hg.sh: allow running from any dir\n>>  + test-lib.sh: convert $TEST_DIRECTORY to an absolute path\n>>  + remote-hg: don't decode UTF-8 paths into Unicode objects\n>>\n>>  Can wait in 'next'.\n>\n> Would it be possible to merge the first commit of this series in\n> master (and eventually in maint) ?\n> My commit (11362653: remote-hg: unquote C-style paths when exporting)\n> breaks the remote-hg tests since v1.8.4.3 (sorry about that), and is\n> fixed by this commit. It would be nice to deliver 1.8.5 with working\n> remote-helpers tests.\n\nSurely.  Let's do that.\n"}]}