{"thread":{"id":"41435","subject":"What's cooking in git.git (Feb 2016, #05; Wed, 17)","startedAt":"2016-02-17T22:34:08Z","lastAt":"2016-02-24T07:58:49Z","messageCount":19,"participants":["Junio C Hamano","Jeff King","Stefan Frühwirth","Johannes Schindelin","Duy Nguyen","Dennis Kaarsemaker"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"278518","messageId":"xmqqio1nge5b.fsf@gitster.mtv.corp.google.com","threadId":"41435","inReplyTo":null,"subject":"What's cooking in git.git (Feb 2016, #05; Wed, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-17T22:34:08Z","receivedAt":"2016-02-17T22:34:08Z","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\nThere are a few undecided topics among the ones that are queued.\n\nYou can find the changes described here in the integration branches of the\nrepositories listed at\n\n    http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* ah/stripspace-optstring (2016-01-29) 1 commit\n  (merged to 'next' on 2016-02-12 at cd021aa)\n + stripspace: call U+0020 a \"space\" instead of a \"blank\"\n\n\n* da/user-useconfigonly (2016-02-08) 2 commits\n  (merged to 'next' on 2016-02-09 at 8b303ce)\n + ident: add user.useConfigOnly boolean for when ident shouldn't be guessed\n + fmt_ident: refactor strictness checks\n\n The \"user.useConfigOnly\" configuration variable can be used to\n force the user to always set user.email & user.name configuration\n variables, serving as a reminder for those who work on multiple\n projects and do not want to put these in their $HOME/.gitconfig.\n\n\n* dw/mergetool-vim-window-shuffle (2016-02-12) 1 commit\n  (merged to 'next' on 2016-02-12 at 2a2e8bd)\n + mergetool: reorder vim/gvim buffers in three-way diffs\n\n The vimdiff backend for \"git mergetool\" has been tweaked to arrange\n and number buffers in the order that would match the expectation of\n majority of people who read left to right, then top down and assign\n buffers 1 2 3 4 \"mentally\" to local base remote merge windows based\n on that order.\n\n\n* jk/drop-rsync-transport (2016-02-01) 1 commit\n  (merged to 'next' on 2016-02-03 at 08be402)\n + transport: drop support for git-over-rsync\n\n It turns out \"git clone\" over rsync transport has been broken when\n the source repository has packed references for a long time, and\n nobody noticed nor complained about it.\n\n\n* jk/rerere-xsnprintf (2016-02-08) 1 commit\n  (merged to 'next' on 2016-02-09 at ff9ade3)\n + rerere: replace strcpy with xsnprintf\n (this branch is used by jc/rerere-multi.)\n\n Some calls to strcpy(3) triggers a false warning from static\n analysers that are less intelligent than humans, and reducing the\n number of these false hits helps us notice real issues.  A few\n calls to strcpy(3) in \"git rerere\" that are already safe has been\n rewritten to avoid false wanings.\n\n\n* jk/test-path-utils-xsnprintf (2016-02-08) 1 commit\n  (merged to 'next' on 2016-02-09 at 931f70b)\n + test-path-utils: use xsnprintf in favor of strcpy\n\n Some calls to strcpy(3) triggers a false warning from static\n analysers that are less intelligent than humans, and reducing the\n number of these false hits helps us notice real issues.  A few\n calls to strcpy(3) in test-path-utils that are already safe has\n been rewritten to avoid false wanings.\n\n\n* js/mingw-tests (2016-02-08) 21 commits\n  (merged to 'next' on 2016-02-08 at 417e555)\n + gitignore: ignore generated test-fake-ssh executable\n  (merged to 'next' on 2016-02-03 at ace7624)\n + mingw: do not bother to test funny file names\n + mingw: skip a test in t9130 that cannot pass on Windows\n + mingw: handle the missing POSIXPERM prereq in t9124\n + mingw: avoid illegal filename in t9118\n + mingw: mark t9100's test cases with appropriate prereqs\n + t0008: avoid absolute path\n + mingw: work around pwd issues in the tests\n + mingw: fix t9700's assumption about directory separators\n + mingw: skip test in t1508 that fails due to path conversion\n + tests: turn off git-daemon tests if FIFOs are not available\n + mingw: disable mkfifo-based tests\n + mingw: accomodate t0060-path-utils for MSYS2\n + mingw: fix t5601-clone.sh\n + mingw: let lstat() fail with errno == ENOTDIR when appropriate\n + mingw: try to delete target directory before renaming\n + mingw: prepare the TMPDIR environment variable for shell scripts\n + mingw: factor out Windows specific environment setup\n + Git.pm: stop assuming that absolute paths start with a slash\n + mingw: do not trust MSYS2's MinGW gettext.sh\n + mingw: let's use gettext with MSYS2\n (this branch is used by mg/mingw-test-fix.)\n\n Test scripts have been updated to remove assumptions that are not\n portable between Git for POSIX and Git for Windows, or to skip ones\n with expectations that are not satisfiable on Git for Windows.\n\n\n* mg/mingw-test-fix (2016-02-08) 1 commit\n  (merged to 'next' on 2016-02-12 at df77956)\n + t9100: fix breakage when SHELL_PATH is not /bin/sh\n (this branch uses js/mingw-tests.)\n\n An earlier adjustment of test mistakenly used write_script\n to prepare a file whose exact content matters for the test;\n reverting that part fixes the breakage for those who use\n SHELL_PATH that is different from /bin/sh.\n\n\n* mm/clean-doc-fix (2016-02-09) 1 commit\n  (merged to 'next' on 2016-02-09 at ced8555)\n + Documentation/git-clean.txt: don't mention deletion of .git/modules/*\n\n The documentation for \"git clean\" has been corrected; it mentioned\n that .git/modules/* are removed by giving two \"-f\", which has never\n been the case.\n\n\n* nd/clear-gitenv-upon-use-of-alias (2016-02-02) 4 commits\n  (merged to 'next' on 2016-02-09 at 2c441b4)\n + restore_env(): free the saved environment variable once we are done\n + git: simplify environment save/restore logic\n + git: protect against unbalanced calls to {save,restore}_env()\n + git: remove an early return from save_env_before_alias()\n\n The automatic typo correction applied to an alias was broken\n with a recent change already in 'master'.\n\n--------------------------------------------------\n[New Topics]\n\n* cn/deprecate-ssh-git-url (2016-02-15) 1 commit\n - Disown ssh+git and git+ssh\n\n Needs toning down by replacing the condescendence with an\n explanation and enlightenment.\n ($gmane/286222)\n\n\n* jk/config-include (2016-02-13) 1 commit\n - git-config: better document default behavior for `--include`\n\n Will merge to 'next'.\n\n\n* nd/git-common-dir-fix (2016-02-12) 1 commit\n - rev-parse: take prefix into account in --git-common-dir\n\n Will merge to 'next'.\n\n\n* sp/remote-curl-ssl-strerror (2016-02-15) 1 commit\n - remote-curl: include curl_errorstr on SSL setup failures\n\n Help those who debug http(s) part of the system.\n\n Will merge to 'next'.\n\n\n* bc/http-empty-auth (2016-02-15) 1 commit\n - http: add option to try authentication without username\n\n Some authentication methods do not need username or password, but\n libcurl needs some hint that it needs to perform authentication.\n Supplying an empty username and password string is a valid way to\n do so, but you can set the http.[<url>.]emptyAuth configuration\n variable to achieve the same, if you find it cleaner.\n\n Will merge to 'next'.\n\n\n* ce/https-public-key-pinning (2016-02-15) 1 commit\n - http: implement public key pinning\n\n You can now set http.[<url>.]pinnedpubkey to specify the pinned\n public key when building with recent enough versions of libcURL.\n\n Will merge to 'next'.\n\n\n* ew/connect-verbose (2016-02-15) 1 commit\n - t5570: add tests for \"git {clone,fetch,pull} -v\"\n\n Will merge to 'next'.\n\n\n* fa/merge-recursive-no-rename (2016-02-17) 2 commits\n - merge-recursive: more consistent interface\n - merge-recursive: option to disable renames\n\n \"git merge-recursive\" learned \"--no-renames\" option to disable its\n rename detection logic.\n\n Will merge to 'next'.\n\n\n* jc/am-i-v-fix (2016-02-17) 3 commits\n - am -i: fix \"v\"iew\n - pager: factor out a helper to prepare a child process to run the pager\n - pager: lose a separate argv[]\n\n The \"v(iew)\" subcommand of the interactive \"git am -i\" command was\n broken in 2.6.0 timeframe when the command was rewritten in C.\n\n Will merge to 'next'.\n\n\n* jk/merge-tree-merge-blobs (2016-02-16) 1 commit\n - merge_blobs: use strbuf instead of manually-sized mmfile_t\n\n \"git merge-tree\" (a throw-away demonstration) did not work very\n well when merging \"both sides added a new file at the same path\"\n case.\n\n Undecided; we might be better off deleting it altogether.\n\n\n* jk/tighten-alloc (2016-02-15) 18 commits\n - ewah: convert to REALLOC_ARRAY, etc\n - convert ewah/bitmap code to use xmalloc\n - diff_populate_gitlink: use a strbuf\n - transport_anonymize_url: use xstrfmt\n - git-compat-util: drop mempcpy compat code\n - sequencer: simplify memory allocation of get_message\n - test-path-utils: fix normalize_path_copy output buffer size\n - fetch-pack: simplify add_sought_entry\n - fast-import: simplify allocation in start_packfile\n - write_untracked_extension: use FLEX_ALLOC helper\n - use st_add and st_mult for allocation size computation\n - convert trivial cases to FLEX_ARRAY macros\n - use xmallocz to avoid size arithmetic\n - convert trivial cases to ALLOC_ARRAY\n - add helpers for allocating flex-array structs\n - harden REALLOC_ARRAY and xcalloc against size_t overflow\n - tree-diff: catch integer overflow in combine_diff_path allocation\n - add helpers for detecting size_t overflow\n\n Update various codepaths to avoid manually-counted malloc().\n\n Will merge to 'next'.\n\n\n* js/git-remote-add-url-insteadof-test (2016-02-17) 1 commit\n - t5505: 'remote add x y' should work when url.y.insteadOf = x\n\n Will merge to 'next'.\n\n\n* nd/dwim-wildcards-as-pathspecs (2016-02-10) 3 commits\n - get_sha1: don't die() on bogus search strings\n - check_filename: tighten dwim-wildcard ambiguity\n - checkout: reorder check_filename conditional\n\n \"git show 'HEAD:Foo[BAR]Baz'\" did not interpret the argument as a\n rev, i.e. the object named by the the pathname with wildcard\n characters in a tree object.\n\n I lost track of this topic; did we decide that this is a good thing\n to do, or unnecessary noise to only cater to a crazy use case?\n\n\n* nd/exclusion-regression-fix (2016-02-15) 4 commits\n - dir.c: don't exclude whole dir prematurely\n - dir.c: support marking some patterns already matched\n - dir.c: support tracing exclude\n - dir.c: fix match_pathname()\n\n Another try to add support to the ignore mechanism that lets you\n say \"this is excluded\" and then later say \"oh, no, this part (that\n is a subset of the previous part) is not exlucded\".\n\n Will merge to 'next'.\n\n\n* nd/worktree-add-B (2016-02-15) 2 commits\n - worktree add -B: do the checkout test before update branch\n - worktree: fix \"add -B\"\n\n \"git worktree add -B <branchname>\" did not work.\n\n Will merge to 'next'.\n\n\n* ps/config-error (2016-02-17) 16 commits\n - SQUASH\n - config: rename git_config_set_or_die to git_config_set\n - config: rename git_config_set to git_config_set_gently\n - compat: die when unable to set core.precomposeunicode\n - sequencer: die on config error when saving replay opts\n - init-db: die on config errors when initializing empty repo\n - clone: die on config error in cmd_clone\n - remote: die on config error when manipulating remotes\n - remote: die on config error when setting/adding branches\n - remote: die on config error when setting URL\n - submodule--helper: die on config error when cloning module\n - submodule: die on config error when linking modules\n - branch: die on config error when editing branch description\n - branch: die on config error when unsetting upstream\n - branch: report errors in tracking branch setup\n - config: introduce set_or_die wrappers\n\n Many codepaths forget to check return value from git_config_set();\n the function is made to die() to make sure we do not proceed when\n setting a configuration variable failed.\n\n Need to squash the tip two commits into one before moving forward.\n\n\n* ss/commit-dry-run-resolve-merge-to-no-op (2016-02-17) 1 commit\n - wt-status.c: set commitable bit if there is a meaningful merge.\n\n \"git commit --dry-run\" reported \"No, no, you cannot commit.\" in one\n case where \"git commit\" would have allowed you to commit, and this\n improves it a little bit (\"git commit --dry-run --short\" still does\n not give you the correct answer, for example).\n\n\n* tg/git-remote (2016-02-16) 4 commits\n - remote: use remote_is_configured() for add and rename\n - remote: actually check if remote exits\n - remote: simplify remote_is_configured()\n - remote: use parse_config_key\n\n The internal API to interact with \"remote.*\" configuration\n variables has been streamlined.\n\n Will merge to 'next'.\n\n\n* ls/config-origin (2016-02-17) 3 commits\n - config: add '--show-origin' option to print the origin of a config value\n - config: add 'type' to config_source struct that identifies config type\n - t: do not hide Git's exit code in tests using 'nul_to_q'\n\n--------------------------------------------------\n[Stalled]\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* 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 Needs review.\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\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* mg/httpd-tests-update-for-apache-2.4 (2015-04-08) 2 commits\n - t/lib-git-svn: check same httpd module dirs as lib-httpd\n - t/lib-httpd: load mod_unixd\n\n This is the first two commits in a three-patch series $gmane/266962\n\n Becoming tired of waiting for a reroll.\n with updated log message ($gmane/268061).\n Will discard.\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* ep/format-printf (2016-02-11) 22 commits\n - wt-status.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - utf8.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - transport-helper.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - trace.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - strbuf.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - remote.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - pkt-line.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - merge-recursive.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - imap-send.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - http-backend.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - fsck.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - daemon.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - config.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - color.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - cache.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - builtin/upload-archive.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - builtin/update-index.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - builtin/receive-pack.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - builtin/index-pack.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - argv-array.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - advice.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'\n - git-compat-util.h: add the FORMAT_PRINTF macro\n\n Undecided.\n\n\n* ew/force-ipv4 (2016-02-12) 1 commit\n - connect & http: support -4 and -6 switches for remote operations\n\n \"git fetch\" and friends that make network connections can now be\n told to only use ipv4 (or ipv6).\n\n Will merge to 'next'.\n\n\n* jk/lose-name-path (2016-02-12) 5 commits\n - list-objects: pass full pathname to callbacks\n - list-objects: drop name_path entirely\n - list-objects: convert name_path to a strbuf\n - show_object_with_name: simplify by using path_name()\n - http-push: stop using name_path\n\n The \"name_path\" API was an attempt to reduce the need to construct\n the full path out of a series of path components while walking a\n tree hierarchy, but over time made less efficient because the path\n needs to be flattened, e.g. to be compared with another path that\n is already flat.  Remove the API and rewrite its users to simplify\n overall code complexity.\n\n Will merge to 'next'.\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 ($gmane/286137)\n\n\n* tb/conversion (2016-02-10) 6 commits\n  (merged to 'next' on 2016-02-12 at 6faf27b)\n + convert.c: simplify text_stat\n + convert.c: refactor crlf_action\n + convert.c: use text_eol_is_crlf()\n + convert.c: remove input_crlf_action()\n + convert.c: remove unused parameter 'path'\n + t0027: add tests for get_stream_filter()\n\n Will be rerolled.\n ($gmane/286219)\n\n\n* sb/submodule-parallel-update (2016-02-13) 7 commits\n - clone: allow an explicit argument for parallel submodule clones\n - submodule update: expose parallelism to the user\n - git submodule update: have a dedicated helper for cloning\n - submodule update: direct error message to stderr\n - fetching submodules: respect `submodule.fetchJobs` config option\n - submodule-config: drop check against NULL\n - submodule-config: keep update strategy around\n (this branch is used by dt/refs-backend-lmdb and sb/submodule-init.)\n\n A major part of \"git submodule update\" has been ported to C to take\n advantage of the recently added framework to run download tasks in\n parallel.\n\n Comments?\n\n\n* dt/refs-backend-lmdb (2016-02-13) 22 commits\n - refs: tests for lmdb backend\n - refs: add LMDB refs storage backend\n - refs: add register_ref_storage_backends()\n - svn: learn ref-storage argument\n - clone: allow ref storage backend to be set for clone\n - refs: check submodules ref storage config\n - init: allow alternate ref strorage to be set for new repos\n - refs: always handle non-normal refs in files backend\n - refs: resolve symbolic refs first\n - refs: allow log-only updates\n - refs: move duplicate check to common code\n - refs: make lock generic\n - refs: add method to rename refs\n - refs: add methods to init refs db\n - refs: add method for delete_refs\n - refs: add method for initial ref transaction commit\n - refs: add methods for reflog\n - refs: add do_for_each_per_worktree_ref\n - refs: add methods for the ref iterators\n - refs: add methods for misc ref operations\n - refs: add a backend method structure with transaction functions\n - Merge branch 'sb/submodule-parallel-update' into dt/refs-backend-lmdb\n (this branch uses sb/submodule-parallel-update; is tangled with sb/submodule-init.)\n\n Building on top of a few refs-backend preparatory series, LMDB\n based refs backend has been plugged into the system.\n\n Will be rerolled.\n ($gmane/285604)\n\n\n* kn/ref-filter-atom-parsing (2016-02-17) 11 commits\n - ref-filter: introduce objectname_atom_parser()\n - ref-filter: introduce contents_atom_parser()\n - ref-filter: introduce remote_ref_atom_parser()\n - ref-filter: align: introduce long-form syntax\n - ref-filter: introduce align_atom_parser()\n - ref-filter: introduce parse_align_position()\n - ref-filter: introduce color_atom_parser()\n - ref-filter: introduce parsing functions for each valid atom\n - ref-filter: introduce struct used_atom\n - ref-filter: bump 'used_atom' and related code to the top\n - ref-filter: use string_list_split over strbuf_split\n\n Refactoring of ref-filter's format-parsing code, in preparation\n for \"branch --format\" and friends.\n\n Will merge to 'next'.\n\n\n* ad/cygwin-wants-rename (2015-08-07) 1 commit\n - config.mak.uname: Cygwin needs OBJECT_CREATION_USES_RENAMES\n\n Will hold.\n ($gmane/275680).\n\n\n* jc/rerere-multi (2016-02-08) 7 commits\n - rerere: do use multiple variants\n - t4200: rerere a merge with two identical conflicts\n - rerere: allow multiple variants to exist\n - rerere: delay the recording of preimage\n - rerere: handle leftover rr-cache/$ID directory and postimage files\n - rerere: scan $GIT_DIR/rr-cache/$ID when instantiating a rerere_id\n - rerere: split conflict ID further\n\n \"git rerere\" can encounter two or more files with the same conflict\n signature that have to be resolved in different ways, but there was\n no way to record these separate resolutions.\n\n Needs further work on forget/gc.\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.  It has been reported that\n git-gui still uses the deprecated syntax, which needs to be fixed\n before this final step can proceed.\n ($gmane/282594)\n\n--------------------------------------------------\n[Discarded]\n\n* dv/http-try-negotiate-at-least-once (2016-02-02) 1 commit\n . remote-curl: don't fall back to Basic auth if we haven't tried Negotiate\n\n bc/http-empty-auth satisfies the original need that triggered this\n topic better.\n"},{"id":"278519","messageId":"20160217232556.GA26077@sigill.intra.peff.net","threadId":"41435","inReplyTo":"xmqqio1nge5b.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Feb 2016, #05; Wed, 17)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-17T23:25:56Z","receivedAt":"2016-02-17T23:25:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 17, 2016 at 02:34:08PM -0800, Junio C Hamano wrote:\n\n> * jk/tighten-alloc (2016-02-15) 18 commits\n>  - ewah: convert to REALLOC_ARRAY, etc\n>  - convert ewah/bitmap code to use xmalloc\n>  - diff_populate_gitlink: use a strbuf\n>  - transport_anonymize_url: use xstrfmt\n>  - git-compat-util: drop mempcpy compat code\n>  - sequencer: simplify memory allocation of get_message\n>  - test-path-utils: fix normalize_path_copy output buffer size\n>  - fetch-pack: simplify add_sought_entry\n>  - fast-import: simplify allocation in start_packfile\n>  - write_untracked_extension: use FLEX_ALLOC helper\n>  - use st_add and st_mult for allocation size computation\n>  - convert trivial cases to FLEX_ARRAY macros\n>  - use xmallocz to avoid size arithmetic\n>  - convert trivial cases to ALLOC_ARRAY\n>  - add helpers for allocating flex-array structs\n>  - harden REALLOC_ARRAY and xcalloc against size_t overflow\n>  - tree-diff: catch integer overflow in combine_diff_path allocation\n>  - add helpers for detecting size_t overflow\n> \n>  Update various codepaths to avoid manually-counted malloc().\n> \n>  Will merge to 'next'.\n\nPlease hold off a bit; I have a re-roll coming for this one.\n\n> * nd/dwim-wildcards-as-pathspecs (2016-02-10) 3 commits\n>  - get_sha1: don't die() on bogus search strings\n>  - check_filename: tighten dwim-wildcard ambiguity\n>  - checkout: reorder check_filename conditional\n> \n>  \"git show 'HEAD:Foo[BAR]Baz'\" did not interpret the argument as a\n>  rev, i.e. the object named by the the pathname with wildcard\n>  characters in a tree object.\n> \n>  I lost track of this topic; did we decide that this is a good thing\n>  to do, or unnecessary noise to only cater to a crazy use case?\n\nI think what we ended up with (and what you have queued here) is an\nimprovement.\n\nI had some question about the tip one, which is a kind-of follow-on, and\nmakes the error message you get in certain cases a bit less\nnon-specific. You were \"on the fence...but slightly inclined to take\"\nit.\n\nEven if we drop it, I think the first two patches are an improvement.\n\n-Peff\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/285935\n"},{"id":"278564","messageId":"xmqqegc9hpox.fsf@gitster.mtv.corp.google.com","threadId":"41435","inReplyTo":"20160217232556.GA26077@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Feb 2016, #05; Wed, 17)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-18T17:51:42Z","receivedAt":"2016-02-18T17:51:42Z","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> On Wed, Feb 17, 2016 at 02:34:08PM -0800, Junio C Hamano wrote:\n>\n>> * jk/tighten-alloc (2016-02-15) 18 commits\n>> ...\n> Please hold off a bit; I have a re-roll coming for this one.\n>\n>> * nd/dwim-wildcards-as-pathspecs (2016-02-10) 3 commits\n>> ...\n> Even if we drop it, I think the first two patches are an improvement.\n\nThanks.\n"},{"id":"278909","messageId":"20160222221209.GA18522@sigill.intra.peff.net","threadId":"41435","inReplyTo":"xmqqio1nge5b.fsf@gitster.mtv.corp.google.com","subject":"whither merge-tree? (was: What's cooking in git.git (Feb 2016, #05; Wed, 17))","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-22T22:12:10Z","receivedAt":"2016-02-22T22:12:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 17, 2016 at 02:34:08PM -0800, Junio C Hamano wrote:\n\n> * jk/merge-tree-merge-blobs (2016-02-16) 1 commit\n>  - merge_blobs: use strbuf instead of manually-sized mmfile_t\n> \n>  \"git merge-tree\" (a throw-away demonstration) did not work very\n>  well when merging \"both sides added a new file at the same path\"\n>  case.\n> \n>  Undecided; we might be better off deleting it altogether.\n\nWhat do we want to do with this? I think there are basically three\noptions:\n\n  1. Take the patch you queued above. That's the minimal fix with no\n     user-visible changes.\n\n  2. Rip out the weird add/add conflict resolution. This gets rid of the\n     buggy code, makes merge-tree more like the rest of git, and I think\n     lets us even drop the EMIT_COMMON stuff from xdiff).\n\n     That lets people keep using merge-tree if they have found it useful\n     over the years.\n\n  3. Drop merge-tree completely. This deletes even more code, and helps\n     the people in (2) realize that it is utterly unmaintained. :)\n\nI think at this point I am waffling between (2) and (3). I did (1) in a\nhope that I could avoid looking deeper into the code at all, but now\nthat I have, I do not think (2) would be so bad. I'm happy to work up a\npatch, but won't bother if we think that (3) is viable.\n\n-Peff\n"},{"id":"278944","messageId":"xmqqsi0k4b52.fsf@gitster.mtv.corp.google.com","threadId":"41435","inReplyTo":"20160222221209.GA18522@sigill.intra.peff.net","subject":"Re: whither merge-tree?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-22T22:45:45Z","receivedAt":"2016-02-22T22:45:45Z","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>   2. Rip out the weird add/add conflict resolution. This gets rid of the\n>      buggy code, makes merge-tree more like the rest of git, and I think\n>      lets us even drop the EMIT_COMMON stuff from xdiff).\n\nThat is a nice bonus.\n\ngit-merge-resolve (rather, git-merge-one-file) attempts the same\n\"resolve add/add by taking the common\" thing, but it implements it\nin quite a different way.\n\n>      That lets people keep using merge-tree if they have found it useful\n>      over the years.\n\n>   3. Drop merge-tree completely. This deletes even more code, and helps\n>      the people in (2) realize that it is utterly unmaintained. :)\n>\n> I think at this point I am waffling between (2) and (3). I did (1) in a\n> hope that I could avoid looking deeper into the code at all, but now\n> that I have, I do not think (2) would be so bad. I'm happy to work up a\n> patch, but won't bother if we think that (3) is viable.\n\nYup, between 2 and 3, 2 would certainly be safer, and I agree that\nit is not too bad (I have this feeling that add-add conflict is not\nthe only funny this code has, though).\n\nLet's wait and see how many \"please don't\"s we hear, perhaps, before\ndeciding to go 3.?\n"},{"id":"278965","messageId":"20160223050210.GA17767@sigill.intra.peff.net","threadId":"41435","inReplyTo":"xmqqsi0k4b52.fsf@gitster.mtv.corp.google.com","subject":"Re: whither merge-tree?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-23T05:02:11Z","receivedAt":"2016-02-23T05:02:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 22, 2016 at 02:45:45PM -0800, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> >   2. Rip out the weird add/add conflict resolution. This gets rid of the\n> >      buggy code, makes merge-tree more like the rest of git, and I think\n> >      lets us even drop the EMIT_COMMON stuff from xdiff).\n> \n> That is a nice bonus.\n> \n> git-merge-resolve (rather, git-merge-one-file) attempts the same\n> \"resolve add/add by taking the common\" thing, but it implements it\n> in quite a different way.\n\nI suppose the end result of what merge-tree is trying to do makes sense.\nIt's definitely a conflict, but we are interested in showing the minimal\ncontent-level conflict. But I think xdl_merge() takes care of that for\nus, if we simply feed an empty base. And that is what merge-recursive\ndoes.\n\nI do see that merge-one-file tries create_virtual_base(), which does\nsome magic with diff. But I'm having trouble conceiving of a case where\nthat would do something different or useful.\n\n> >      That lets people keep using merge-tree if they have found it useful\n> >      over the years.\n> \n> >   3. Drop merge-tree completely. This deletes even more code, and helps\n> >      the people in (2) realize that it is utterly unmaintained. :)\n> >\n> > I think at this point I am waffling between (2) and (3). I did (1) in a\n> > hope that I could avoid looking deeper into the code at all, but now\n> > that I have, I do not think (2) would be so bad. I'm happy to work up a\n> > patch, but won't bother if we think that (3) is viable.\n> \n> Yup, between 2 and 3, 2 would certainly be safer, and I agree that\n> it is not too bad (I have this feeling that add-add conflict is not\n> the only funny this code has, though).\n\nYeah, I do not mind doing 2, but I have no idea what else is lurking,\nand I have very little interest in digging into it.\n\n> Let's wait and see how many \"please don't\"s we hear, perhaps, before\n> deciding to go 3.?\n\nI'm guessing we won't see much either way. Even Stefan, the original\nreporter, does not seem to actively be using it, but rather relaying a\nreport.\n\nWe'd probably get more response by doing 2 for now, then adding a\ndeprecation warning to the manpage (and possibly the program itself) for\nthe next release.\n\n-Peff\n"},{"id":"278966","messageId":"20160223051402.GA23375@sigill.intra.peff.net","threadId":"41435","inReplyTo":"20160223050210.GA17767@sigill.intra.peff.net","subject":"Re: whither merge-tree?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-23T05:14:02Z","receivedAt":"2016-02-23T05:14:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 23, 2016 at 12:02:10AM -0500, Jeff King wrote:\n\n> > git-merge-resolve (rather, git-merge-one-file) attempts the same\n> > \"resolve add/add by taking the common\" thing, but it implements it\n> > in quite a different way.\n> \n> I suppose the end result of what merge-tree is trying to do makes sense.\n> It's definitely a conflict, but we are interested in showing the minimal\n> content-level conflict. But I think xdl_merge() takes care of that for\n> us, if we simply feed an empty base. And that is what merge-recursive\n> does.\n> \n> I do see that merge-one-file tries create_virtual_base(), which does\n> some magic with diff. But I'm having trouble conceiving of a case where\n> that would do something different or useful.\n\nI dug this all the way down to your cb93c19 (merge-one-file: use common\nas base, instead of emptiness., 2005-11-09), which states that the goal\nis just to get:\n\n\tcommon file contents...\n\t<<<<<< FILENAME\n\tversion from our branch...\n\t======\n\tversion from their branch...\n\t>>>>>> .merge_file_XXXXXX\n\tmore common file contents...\n\nBut that seems to be what we produce now. Did all of this simply predate\nxdl_merge, and the crappy rcs merge did not bother minimizing the diff?\nThat certainly seems to be the case in my tests.\n\nIf that is the case, I think we can get rid of the complex\ncreate_virtual_base(), as well.\n\n-Peff\n"},{"id":"278968","messageId":"20160223060338.GA2912@sigill.intra.peff.net","threadId":"41435","inReplyTo":"20160223051402.GA23375@sigill.intra.peff.net","subject":"Re: whither merge-tree?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-23T06:03:38Z","receivedAt":"2016-02-23T06:03:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 23, 2016 at 12:14:02AM -0500, Jeff King wrote:\n\n> I dug this all the way down to your cb93c19 (merge-one-file: use common\n> as base, instead of emptiness., 2005-11-09), which states that the goal\n> is just to get:\n> \n> \tcommon file contents...\n> \t<<<<<< FILENAME\n> \tversion from our branch...\n> \t======\n> \tversion from their branch...\n> \t>>>>>> .merge_file_XXXXXX\n> \tmore common file contents...\n> \n> But that seems to be what we produce now. Did all of this simply predate\n> xdl_merge, and the crappy rcs merge did not bother minimizing the diff?\n> That certainly seems to be the case in my tests.\n> \n> If that is the case, I think we can get rid of the complex\n> create_virtual_base(), as well.\n\nSo here is what I would propose:\n\n  [1/3]: merge-one-file: use empty blob for add/add base\n  [2/3]: merge-tree: drop generate_common strategy\n  [3/3]: xdiff: drop XDL_EMIT_COMMON\n\nI briefly wondered if there were any bugs in merge-one-file around this\n\"no newline at end of file\" issue. But there shouldn't be. It generates\nthe common file by applying the diff to the first file with \"--no-add\",\nwhich should do the right thing, I think.\n\nI stopped short of dropping the create_virtual_base function in the\nfirst patch, for reasons explained there. But if we were to do so, I\nsuspect we could deprecated and eventually drop \"apply --no-add\", too.\n\n-Peff\n"},{"id":"278969","messageId":"20160223060441.GA3205@sigill.intra.peff.net","threadId":"41435","inReplyTo":"20160223060338.GA2912@sigill.intra.peff.net","subject":"[PATCH 1/3] merge-one-file: use empty blob for add/add base","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-23T06:04:41Z","receivedAt":"2016-02-23T06:04:41Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"When we see an add/add conflict on a file, we generate the\nconflicted content by doing a 3-way merge with a \"virtual\"\nbase consisting of the common lines of the two sides. This\nstrategy dates back to cb93c19 (merge-one-file: use common\nas base, instead of emptiness., 2005-11-09).\n\nBack then, the next step was to call rcs merge to generate\nthe 3-way conflicts. Using the virtual base produced much\nbetter results, as rcs merge does not attempt to minimize\nthe hunks. As a result, you'd get a conflict with the\nentirety of the files on either side.\n\nSince then, though, we've switched to using git-merge-file,\nwhich uses xdiff's \"zealous\" merge. This will find the\nminimal hunks even with just the simple, empty base.\n\nLet's switch to using that empty base. It's simpler, more\nefficient, and reduces our dependencies (we no longer need a\nworking diff binary). It's also how the merge-recursive\nstrategy handles this same case.\n\nWe can almost get rid of git-sh-setup's create_virtual_base,\nbut we don't here, for two reasons:\n\n  1. The functions in git-sh-setup are part of our public\n     interface, so it's possible somebody is depending on\n     it. We'd at least need to deprecate it first.\n\n  2. It's also used by mergetool's p4merge driver. It's\n     unknown whether its 3-way merge is as capable as git's;\n     if not, then it is benefiting from the function.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n git-merge-one-file.sh | 3 +--\n 1 file changed, 1 insertion(+), 2 deletions(-)\n\ndiff --git a/git-merge-one-file.sh b/git-merge-one-file.sh\nindex cdc02af..424b034 100755\n--- a/git-merge-one-file.sh\n+++ b/git-merge-one-file.sh\n@@ -120,8 +120,7 @@ case \"${1:-.}${2:-.}${3:-.}\" in\n \tcase \"$1\" in\n \t'')\n \t\techo \"Added $4 in both, but differently.\"\n-\t\torig=$(git-unpack-file $2)\n-\t\tcreate_virtual_base \"$orig\" \"$src2\"\n+\t\torig=$(git-unpack-file e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)\n \t\t;;\n \t*)\n \t\techo \"Auto-merging $4\"\n-- \n2.7.2.645.g4e1306c\n"},{"id":"278970","messageId":"20160223060655.GB3205@sigill.intra.peff.net","threadId":"41435","inReplyTo":"20160223060338.GA2912@sigill.intra.peff.net","subject":"[PATCH 2/3] merge-tree: drop generate_common strategy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-23T06:06:55Z","receivedAt":"2016-02-23T06:06:55Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"When merge_blobs sees an add/add conflict, it tries to\ncreate a virtual base object for the 3-way merge that\nconsists of the common lines of each file. It inherited this\nstrategy from merge-one-file in 0c79938 (Improved three-way\nblob merging code, 2006-06-28), and the point is to minimize\nthe size of the conflict hunks. That commit talks about \"if\nlibxdiff were to ever grow a compatible three-way merge, it\ncould probably be directly plugged in\".\n\nThat has long since happened. So as with merge-one-file in\nthe previous commit, this extra step is no longer necessary.\nOur 3-way merge code is smart enough to do the minimizing\nitself if we simply feed it an empty base, which is what the\nmore modern merge-recursive strategy already does.\n\nNot only does this let us drop some code, but it removes an\noverflow bug in generate_common_file(). We allocate a buffer\nas large as the smallest of the two blobs, under the\nassumption that there cannot be more common content than\nwhat is in the smaller blob. However, xdiff may feed us\nmore: if neither file ends in a newline, it feeds us the\n\"\\nNo newline at end of file\" marker as common content, and\nwe write it into the output. If the differences between the\nfiles are small than that string, we overflow the output\nbuffer.  This patch solves it by simply dropping the buggy\ncode entirely.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n merge-blobs.c | 38 ++------------------------------------\n 1 file changed, 2 insertions(+), 36 deletions(-)\n\ndiff --git a/merge-blobs.c b/merge-blobs.c\nindex ddca601..9b6eac2 100644\n--- a/merge-blobs.c\n+++ b/merge-blobs.c\n@@ -48,40 +48,6 @@ static void *three_way_filemerge(const char *path, mmfile_t *base, mmfile_t *our\n \treturn res.ptr;\n }\n \n-static int common_outf(void *priv_, mmbuffer_t *mb, int nbuf)\n-{\n-\tint i;\n-\tmmfile_t *dst = priv_;\n-\n-\tfor (i = 0; i < nbuf; i++) {\n-\t\tmemcpy(dst->ptr + dst->size, mb[i].ptr, mb[i].size);\n-\t\tdst->size += mb[i].size;\n-\t}\n-\treturn 0;\n-}\n-\n-static int generate_common_file(mmfile_t *res, mmfile_t *f1, mmfile_t *f2)\n-{\n-\tunsigned long size = f1->size < f2->size ? f1->size : f2->size;\n-\tvoid *ptr = xmalloc(size);\n-\txpparam_t xpp;\n-\txdemitconf_t xecfg;\n-\txdemitcb_t ecb;\n-\n-\tmemset(&xpp, 0, sizeof(xpp));\n-\txpp.flags = 0;\n-\tmemset(&xecfg, 0, sizeof(xecfg));\n-\txecfg.ctxlen = 3;\n-\txecfg.flags = XDL_EMIT_COMMON;\n-\tecb.outf = common_outf;\n-\n-\tres->ptr = ptr;\n-\tres->size = 0;\n-\n-\tecb.priv = res;\n-\treturn xdi_diff(f1, f2, &xpp, &xecfg, &ecb);\n-}\n-\n void *merge_blobs(const char *path, struct blob *base, struct blob *our, struct blob *their, unsigned long *size)\n {\n \tvoid *res = NULL;\n@@ -112,8 +78,8 @@ void *merge_blobs(const char *path, struct blob *base, struct blob *our, struct\n \t\tif (fill_mmfile_blob(&common, base) < 0)\n \t\t\tgoto out_free_f2_f1;\n \t} else {\n-\t\tif (generate_common_file(&common, &f1, &f2) < 0)\n-\t\t\tgoto out_free_f2_f1;\n+\t\tcommon.ptr = xstrdup(\"\");\n+\t\tcommon.size = 0;\n \t}\n \tres = three_way_filemerge(path, &common, &f1, &f2, size);\n \tfree_mmfile(&common);\n-- \n2.7.2.645.g4e1306c\n"},{"id":"278971","messageId":"20160223060725.GC3205@sigill.intra.peff.net","threadId":"41435","inReplyTo":"20160223060338.GA2912@sigill.intra.peff.net","subject":"[PATCH 3/3] xdiff: drop XDL_EMIT_COMMON","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-23T06:07:25Z","receivedAt":"2016-02-23T06:07:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"There are no more callers that use this mode, and none\nlikely to be added (as our xdl_merge() eliminates the common\nuse of it for generating 3-way merge bases).\n\nThis is effectively a revert of a9ed376 (xdiff: generate\n\"anti-diffs\" aka what is common to two files, 2006-06-28),\nthough of course trying to revert that ancient commit\ndirectly produces many textual conflicts.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n xdiff/xdiff.h |  1 -\n xdiff/xemit.c | 18 ------------------\n 2 files changed, 19 deletions(-)\n\ndiff --git a/xdiff/xdiff.h b/xdiff/xdiff.h\nindex c033991..4fb7e79 100644\n--- a/xdiff/xdiff.h\n+++ b/xdiff/xdiff.h\n@@ -42,7 +42,6 @@ extern \"C\" {\n #define XDF_IGNORE_BLANK_LINES (1 << 7)\n \n #define XDL_EMIT_FUNCNAMES (1 << 0)\n-#define XDL_EMIT_COMMON (1 << 1)\n #define XDL_EMIT_FUNCCONTEXT (1 << 2)\n \n #define XDL_MMB_READONLY (1 << 0)\ndiff --git a/xdiff/xemit.c b/xdiff/xemit.c\nindex 4266ada..993724b 100644\n--- a/xdiff/xemit.c\n+++ b/xdiff/xemit.c\n@@ -120,21 +120,6 @@ static long def_ff(const char *rec, long len, char *buf, long sz, void *priv)\n \treturn -1;\n }\n \n-static int xdl_emit_common(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,\n-                           xdemitconf_t const *xecfg) {\n-\txdfile_t *xdf = &xe->xdf2;\n-\tconst char *rchg = xdf->rchg;\n-\tlong ix;\n-\n-\tfor (ix = 0; ix < xdf->nrec; ix++) {\n-\t\tif (rchg[ix])\n-\t\t\tcontinue;\n-\t\tif (xdl_emit_record(xdf, ix, \"\", ecb))\n-\t\t\treturn -1;\n-\t}\n-\treturn 0;\n-}\n-\n struct func_line {\n \tlong len;\n \tchar buf[80];\n@@ -170,9 +155,6 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,\n \tlong funclineprev = -1;\n \tstruct func_line func_line = { 0 };\n \n-\tif (xecfg->flags & XDL_EMIT_COMMON)\n-\t\treturn xdl_emit_common(xe, xscr, ecb, xecfg);\n-\n \tfor (xch = xscr; xch; xch = xche->next) {\n \t\txche = xdl_get_hunk(&xch, xecfg);\n \t\tif (!xch)\n-- \n2.7.2.645.g4e1306c\n"},{"id":"278975","messageId":"xmqqr3g42atl.fsf@gitster.mtv.corp.google.com","threadId":"41435","inReplyTo":"20160223060338.GA2912@sigill.intra.peff.net","subject":"Re: whither merge-tree?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-23T06:35:34Z","receivedAt":"2016-02-23T06:35:34Z","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> On Tue, Feb 23, 2016 at 12:14:02AM -0500, Jeff King wrote:\n>\n>> I dug this all the way down to your cb93c19 (merge-one-file: use common\n>> as base, instead of emptiness., 2005-11-09), which states that the goal\n>> is just to get:\n>> \n>> \tcommon file contents...\n>> \t<<<<<< FILENAME\n>> \tversion from our branch...\n>> \t======\n>> \tversion from their branch...\n>> \t>>>>>> .merge_file_XXXXXX\n>> \tmore common file contents...\n>> \n>> But that seems to be what we produce now. Did all of this simply predate\n>> xdl_merge, and the crappy rcs merge did not bother minimizing the diff?\n>> That certainly seems to be the case in my tests.\n>> \n>> If that is the case, I think we can get rid of the complex\n>> create_virtual_base(), as well.\n>\n> So here is what I would propose:\n>\n>   [1/3]: merge-one-file: use empty blob for add/add base\n>   [2/3]: merge-tree: drop generate_common strategy\n>   [3/3]: xdiff: drop XDL_EMIT_COMMON\n>\n> I briefly wondered if there were any bugs in merge-one-file around this\n> \"no newline at end of file\" issue. But there shouldn't be. It generates\n> the common file by applying the diff to the first file with \"--no-add\",\n> which should do the right thing, I think.\n>\n> I stopped short of dropping the create_virtual_base function in the\n> first patch, for reasons explained there. But if we were to do so, I\n> suspect we could deprecated and eventually drop \"apply --no-add\", too.\n\nThanks.  I think the \"virtual\" stuff started its life outside\nsh-setup but later was moved there for p4merge.  The log message for\n4549162e (mergetools/p4merge: create a base if none available,\n2013-03-13) seems to indicate that using an empty file does not work\nwell over there as you suspected, so unfortunately we cannot lose it\njust yet.\n"},{"id":"278984","messageId":"20160223071812.GD8395@sigill.intra.peff.net","threadId":"41435","inReplyTo":"xmqqr3g42atl.fsf@gitster.mtv.corp.google.com","subject":"Re: whither merge-tree?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-23T07:18:12Z","receivedAt":"2016-02-23T07:18:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 22, 2016 at 10:35:34PM -0800, Junio C Hamano wrote:\n\n> > I stopped short of dropping the create_virtual_base function in the\n> > first patch, for reasons explained there. But if we were to do so, I\n> > suspect we could deprecated and eventually drop \"apply --no-add\", too.\n> \n> Thanks.  I think the \"virtual\" stuff started its life outside\n> sh-setup but later was moved there for p4merge.  The log message for\n> 4549162e (mergetools/p4merge: create a base if none available,\n> 2013-03-13) seems to indicate that using an empty file does not work\n> well over there as you suspected, so unfortunately we cannot lose it\n> just yet.\n\nOh, indeed. I did find that commit in my git-blaming, but failed to\nactually read it carefully. :)\n\nWith that, yeah, I agree that we cannot drop the virtual-base thing, and\nmy 3 patches are fine as-is.\n\n-Peff\n"},{"id":"278989","messageId":"56CC2B2E.6070203@uni-graz.at","threadId":"41435","inReplyTo":"20160223050210.GA17767@sigill.intra.peff.net","subject":"Re: whither merge-tree?","fromName":"Stefan Frühwirth","fromEmail":"stefan.fruehwirth@uni-graz.at","sentAt":"2016-02-23T09:49:34Z","receivedAt":"2016-02-23T09:49:34Z","isPatch":false,"sender":{"key":"stefan.fruehwirth@uni-graz.at","avatar":null},"body":"On 23.02.2016 at 06:02 Jeff King wrote:\n>> Let's wait and see how many \"please don't\"s we hear, perhaps, before\n>> deciding to go 3.?\n>\n> I'm guessing we won't see much either way. Even Stefan, the original\n> reporter, does not seem to actively be using it, but rather relaying a\n> report.\n\nI _am_ actively using it. Maybe I was unclear on that topic. I'm in \nfavour of keeping it, because this means I don't have to rewrite Chris' \nCode in order to be able to use the Python library that uses merge-tree \n(Acidfs). But as a sensible human being I want what's best in the long \nrun. I leave that up to you as I have no way of assessing that.\n\nSo that's a \"please don't\" leave the code as-is but provide a \n(transitional) solution that fixes the reported bug and has the best \nchances of not causing any more headaches :)\n\n> We'd probably get more response by doing 2 for now, then adding a\n> deprecation warning to the manpage (and possibly the program itself) for\n> the next release.\n\nA deprecation warning would be very welcome.\n\nThanks,\nStefan\n"},{"id":"278999","messageId":"alpine.DEB.2.20.1602231334050.3152@virtualbox","threadId":"41435","inReplyTo":"20160223050210.GA17767@sigill.intra.peff.net","subject":"Re: whither merge-tree?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-02-23T12:36:36Z","receivedAt":"2016-02-23T12:36:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Tue, 23 Feb 2016, Jeff King wrote:\n\n> On Mon, Feb 22, 2016 at 02:45:45PM -0800, Junio C Hamano wrote:\n> \n> > Jeff King <peff@peff.net> writes:\n> > \n> > >   3. Drop merge-tree completely. This deletes even more code, and\n> > >   helps the people in (2) realize that it is utterly unmaintained.\n> > >   :)\n> >\n> > Let's wait and see how many \"please don't\"s we hear, perhaps, before\n> > deciding to go 3.?\n> \n> I'm guessing we won't see much either way.\n\nWe could encourage more voices by issuing a warning when merge-tree is\ncalled, e.g.:\n\n\twarning: merge-tree is unsupported (please contact\n\t\t git@vger.kernel.org if you use it actively)\n\nCiao,\nDscho\n"},{"id":"279000","messageId":"CACsJy8Aa30TDeSyXaPT1L+VzTMgC+vhJhO+T=j7n6k+9AFi-Eg@mail.gmail.com","threadId":"41435","inReplyTo":"alpine.DEB.2.20.1602231334050.3152@virtualbox","subject":"Re: whither merge-tree?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-02-23T12:41:45Z","receivedAt":"2016-02-23T12:41:45Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 23, 2016 at 7:36 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> We could encourage more voices by issuing a warning when merge-tree is\n> called, e.g.:\n>\n>         warning: merge-tree is unsupported (please contact\n>                  git@vger.kernel.org if you use it actively)\n\nMaybe motivate them to reach git@vger by s/use it actively/do not want it gone/.\n-- \nDuy\n"},{"id":"279125","messageId":"1456298939.5430.1.camel@kaarsemaker.net","threadId":"41435","inReplyTo":"56CC2B2E.6070203@uni-graz.at","subject":"Re: whither merge-tree?","fromName":"Dennis Kaarsemaker","fromEmail":"dennis@kaarsemaker.net","sentAt":"2016-02-24T07:28:59Z","receivedAt":"2016-02-24T07:28:59Z","isPatch":false,"sender":{"key":"dennis@kaarsemaker.net","avatar":"https://avatars.githubusercontent.com/u/200649?v=4"},"body":"On di, 2016-02-23 at 10:49 +0100, Stefan Frühwirth wrote:\n> On 23.02.2016 at 06:02 Jeff King wrote:\n> > > Let's wait and see how many \"please don't\"s we hear, perhaps,\n> > > before\n> > > deciding to go 3.?\n> > \n> > I'm guessing we won't see much either way. Even Stefan, the\n> > original\n> > reporter, does not seem to actively be using it, but rather\n> > relaying a\n> > report.\n> \n> I _am_ actively using it. Maybe I was unclear on that topic. I'm in \n> favour of keeping it, because this means I don't have to rewrite\n> Chris' \n> Code in order to be able to use the Python library that uses merge-\n> tree \n> (Acidfs). But as a sensible human being I want what's best in the\n> long \n> run. I leave that up to you as I have no way of assessing that.\n> \n> So that's a \"please don't\" leave the code as-is but provide a \n> (transitional) solution that fixes the reported bug and has the best \n> chances of not causing any more headaches :)\n\nI am also actively using it. It's the only way (I know of) of trying to\npreview a merge result without attempting the actual merge, which is\nuseful in some of my scripts.\n\n-- \nDennis Kaarsemaker\nwww.kaarsemaker.net\n"},{"id":"279133","messageId":"20160224075702.GA12511@sigill.intra.peff.net","threadId":"41435","inReplyTo":"1456298939.5430.1.camel@kaarsemaker.net","subject":"Re: whither merge-tree?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-24T07:57:03Z","receivedAt":"2016-02-24T07:57:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 24, 2016 at 08:28:59AM +0100, Dennis Kaarsemaker wrote:\n\n> > So that's a \"please don't\" leave the code as-is but provide a \n> > (transitional) solution that fixes the reported bug and has the best \n> > chances of not causing any more headaches :)\n> \n> I am also actively using it. It's the only way (I know of) of trying to\n> preview a merge result without attempting the actual merge, which is\n> useful in some of my scripts.\n\nOK. I guess we can live with the series I posted earlier (to simplify\nthe add/add behavior and fix the overflow), and leave it in place.\n\nI _do_ think it's a useful concept, and there isn't something quite like\nit in git right now. At one point I contemplated teaching unpack-trees\nto do the content-level merges too, so you could do this via read-tree,\nbut I didn't ever polish it[1]. So I am sympathetic to the goal, and\nthere's not another way to do it as efficiently.\n\nAnd now I feel like both of you have been warned that the code might be\ncrufty. :)\n\nI'm not sure what we should do about warning others.  Since people are\nusing it, I don't want to put a deprecation warning. It's not \"this will\nbe removed in the next version\" anymore, but \"watch out, this might be\ncrufty\". I guess that can go in the manpage, but I'm not quite sure how\nto word it.\n\n-Peff\n\n[1] It looks like my patch has been collecting dust since 2011:\n\n      git://github.com/peff/git.git jk/read-tree-content-merge-wip\n\n    It's been rebased along with all of my other topics since then, but\n    otherwise I have no clue if it works or even compiles (it's not part\n    of my day-to-day build). Anyone is welcome to use it as a base if\n    they want to pursue it.\n"},{"id":"279134","messageId":"20160224075849.GB12511@sigill.intra.peff.net","threadId":"41435","inReplyTo":"56CC2B2E.6070203@uni-graz.at","subject":"Re: whither merge-tree?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-24T07:58:49Z","receivedAt":"2016-02-24T07:58:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 23, 2016 at 10:49:34AM +0100, Stefan Frühwirth wrote:\n\n> On 23.02.2016 at 06:02 Jeff King wrote:\n> >>Let's wait and see how many \"please don't\"s we hear, perhaps, before\n> >>deciding to go 3.?\n> >\n> >I'm guessing we won't see much either way. Even Stefan, the original\n> >reporter, does not seem to actively be using it, but rather relaying a\n> >report.\n> \n> I _am_ actively using it. Maybe I was unclear on that topic. I'm in favour\n> of keeping it, because this means I don't have to rewrite Chris' Code in\n> order to be able to use the Python library that uses merge-tree (Acidfs).\n> But as a sensible human being I want what's best in the long run. I leave\n> that up to you as I have no way of assessing that.\n\nAh, sorry for the confusion. I had thought you were just relaying bugs\non behalf of acidfs folks, but it makes sense that you are using it\nindirectly through the library.\n\n> So that's a \"please don't\" leave the code as-is but provide a (transitional)\n> solution that fixes the reported bug and has the best chances of not causing\n> any more headaches :)\n\nI think the series I posted does what you want, then, and we can stop\nshort of deprecating for now.\n\n-Peff\n"}]}