What's cooking in git.git (Feb 2016, #05; Wed, 17)

What's cooking in git.git (Feb 2016, #05; Wed, 17)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.  The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.

There are a few undecided topics among the ones that are queued.

You can find the changes described here in the integration branches of the
repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

--------------------------------------------------
[Graduated to "master"]

* ah/stripspace-optstring (2016-01-29) 1 commit
  (merged to 'next' on 2016-02-12 at cd021aa)
 + stripspace: call U+0020 a "space" instead of a "blank"


* da/user-useconfigonly (2016-02-08) 2 commits
  (merged to 'next' on 2016-02-09 at 8b303ce)
 + ident: add user.useConfigOnly boolean for when ident shouldn't be guessed
 + fmt_ident: refactor strictness checks

 The "user.useConfigOnly" configuration variable can be used to
 force the user to always set user.email & user.name configuration
 variables, serving as a reminder for those who work on multiple
 projects and do not want to put these in their $HOME/.gitconfig.


* dw/mergetool-vim-window-shuffle (2016-02-12) 1 commit
  (merged to 'next' on 2016-02-12 at 2a2e8bd)
 + mergetool: reorder vim/gvim buffers in three-way diffs

 The vimdiff backend for "git mergetool" has been tweaked to arrange
 and number buffers in the order that would match the expectation of
 majority of people who read left to right, then top down and assign
 buffers 1 2 3 4 "mentally" to local base remote merge windows based
 on that order.


* jk/drop-rsync-transport (2016-02-01) 1 commit
  (merged to 'next' on 2016-02-03 at 08be402)
 + transport: drop support for git-over-rsync

 It turns out "git clone" over rsync transport has been broken when
 the source repository has packed references for a long time, and
 nobody noticed nor complained about it.


* jk/rerere-xsnprintf (2016-02-08) 1 commit
  (merged to 'next' on 2016-02-09 at ff9ade3)
 + rerere: replace strcpy with xsnprintf
 (this branch is used by jc/rerere-multi.)

 Some calls to strcpy(3) triggers a false warning from static
 analysers that are less intelligent than humans, and reducing the
 number of these false hits helps us notice real issues.  A few
 calls to strcpy(3) in "git rerere" that are already safe has been
 rewritten to avoid false wanings.


* jk/test-path-utils-xsnprintf (2016-02-08) 1 commit
  (merged to 'next' on 2016-02-09 at 931f70b)
 + test-path-utils: use xsnprintf in favor of strcpy

 Some calls to strcpy(3) triggers a false warning from static
 analysers that are less intelligent than humans, and reducing the
 number of these false hits helps us notice real issues.  A few
 calls to strcpy(3) in test-path-utils that are already safe has
 been rewritten to avoid false wanings.


* js/mingw-tests (2016-02-08) 21 commits
  (merged to 'next' on 2016-02-08 at 417e555)
 + gitignore: ignore generated test-fake-ssh executable
  (merged to 'next' on 2016-02-03 at ace7624)
 + mingw: do not bother to test funny file names
 + mingw: skip a test in t9130 that cannot pass on Windows
 + mingw: handle the missing POSIXPERM prereq in t9124
 + mingw: avoid illegal filename in t9118
 + mingw: mark t9100's test cases with appropriate prereqs
 + t0008: avoid absolute path
 + mingw: work around pwd issues in the tests
 + mingw: fix t9700's assumption about directory separators
 + mingw: skip test in t1508 that fails due to path conversion
 + tests: turn off git-daemon tests if FIFOs are not available
 + mingw: disable mkfifo-based tests
 + mingw: accomodate t0060-path-utils for MSYS2
 + mingw: fix t5601-clone.sh
 + mingw: let lstat() fail with errno == ENOTDIR when appropriate
 + mingw: try to delete target directory before renaming
 + mingw: prepare the TMPDIR environment variable for shell scripts
 + mingw: factor out Windows specific environment setup
 + Git.pm: stop assuming that absolute paths start with a slash
 + mingw: do not trust MSYS2's MinGW gettext.sh
 + mingw: let's use gettext with MSYS2
 (this branch is used by mg/mingw-test-fix.)

 Test scripts have been updated to remove assumptions that are not
 portable between Git for POSIX and Git for Windows, or to skip ones
 with expectations that are not satisfiable on Git for Windows.


* mg/mingw-test-fix (2016-02-08) 1 commit
  (merged to 'next' on 2016-02-12 at df77956)
 + t9100: fix breakage when SHELL_PATH is not /bin/sh
 (this branch uses js/mingw-tests.)

 An earlier adjustment of test mistakenly used write_script
 to prepare a file whose exact content matters for the test;
 reverting that part fixes the breakage for those who use
 SHELL_PATH that is different from /bin/sh.


* mm/clean-doc-fix (2016-02-09) 1 commit
  (merged to 'next' on 2016-02-09 at ced8555)
 + Documentation/git-clean.txt: don't mention deletion of .git/modules/*

 The documentation for "git clean" has been corrected; it mentioned
 that .git/modules/* are removed by giving two "-f", which has never
 been the case.


* nd/clear-gitenv-upon-use-of-alias (2016-02-02) 4 commits
  (merged to 'next' on 2016-02-09 at 2c441b4)
 + restore_env(): free the saved environment variable once we are done
 + git: simplify environment save/restore logic
 + git: protect against unbalanced calls to {save,restore}_env()
 + git: remove an early return from save_env_before_alias()

 The automatic typo correction applied to an alias was broken
 with a recent change already in 'master'.

--------------------------------------------------
[New Topics]

* cn/deprecate-ssh-git-url (2016-02-15) 1 commit
 - Disown ssh+git and git+ssh

 Needs toning down by replacing the condescendence with an
 explanation and enlightenment.
 ($gmane/286222)


* jk/config-include (2016-02-13) 1 commit
 - git-config: better document default behavior for `--include`

 Will merge to 'next'.


* nd/git-common-dir-fix (2016-02-12) 1 commit
 - rev-parse: take prefix into account in --git-common-dir

 Will merge to 'next'.


* sp/remote-curl-ssl-strerror (2016-02-15) 1 commit
 - remote-curl: include curl_errorstr on SSL setup failures

 Help those who debug http(s) part of the system.

 Will merge to 'next'.


* bc/http-empty-auth (2016-02-15) 1 commit
 - http: add option to try authentication without username

 Some authentication methods do not need username or password, but
 libcurl needs some hint that it needs to perform authentication.
 Supplying an empty username and password string is a valid way to
 do so, but you can set the http.[<url>.]emptyAuth configuration
 variable to achieve the same, if you find it cleaner.

 Will merge to 'next'.


* ce/https-public-key-pinning (2016-02-15) 1 commit
 - http: implement public key pinning

 You can now set http.[<url>.]pinnedpubkey to specify the pinned
 public key when building with recent enough versions of libcURL.

 Will merge to 'next'.


* ew/connect-verbose (2016-02-15) 1 commit
 - t5570: add tests for "git {clone,fetch,pull} -v"

 Will merge to 'next'.


* fa/merge-recursive-no-rename (2016-02-17) 2 commits
 - merge-recursive: more consistent interface
 - merge-recursive: option to disable renames

 "git merge-recursive" learned "--no-renames" option to disable its
 rename detection logic.

 Will merge to 'next'.


* jc/am-i-v-fix (2016-02-17) 3 commits
 - am -i: fix "v"iew
 - pager: factor out a helper to prepare a child process to run the pager
 - pager: lose a separate argv[]

 The "v(iew)" subcommand of the interactive "git am -i" command was
 broken in 2.6.0 timeframe when the command was rewritten in C.

 Will merge to 'next'.


* jk/merge-tree-merge-blobs (2016-02-16) 1 commit
 - merge_blobs: use strbuf instead of manually-sized mmfile_t

 "git merge-tree" (a throw-away demonstration) did not work very
 well when merging "both sides added a new file at the same path"
 case.

 Undecided; we might be better off deleting it altogether.


* jk/tighten-alloc (2016-02-15) 18 commits
 - ewah: convert to REALLOC_ARRAY, etc
 - convert ewah/bitmap code to use xmalloc
 - diff_populate_gitlink: use a strbuf
 - transport_anonymize_url: use xstrfmt
 - git-compat-util: drop mempcpy compat code
 - sequencer: simplify memory allocation of get_message
 - test-path-utils: fix normalize_path_copy output buffer size
 - fetch-pack: simplify add_sought_entry
 - fast-import: simplify allocation in start_packfile
 - write_untracked_extension: use FLEX_ALLOC helper
 - use st_add and st_mult for allocation size computation
 - convert trivial cases to FLEX_ARRAY macros
 - use xmallocz to avoid size arithmetic
 - convert trivial cases to ALLOC_ARRAY
 - add helpers for allocating flex-array structs
 - harden REALLOC_ARRAY and xcalloc against size_t overflow
 - tree-diff: catch integer overflow in combine_diff_path allocation
 - add helpers for detecting size_t overflow

 Update various codepaths to avoid manually-counted malloc().

 Will merge to 'next'.


* js/git-remote-add-url-insteadof-test (2016-02-17) 1 commit
 - t5505: 'remote add x y' should work when url.y.insteadOf = x

 Will merge to 'next'.


* nd/dwim-wildcards-as-pathspecs (2016-02-10) 3 commits
 - get_sha1: don't die() on bogus search strings
 - check_filename: tighten dwim-wildcard ambiguity
 - checkout: reorder check_filename conditional

 "git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a
 rev, i.e. the object named by the the pathname with wildcard
 characters in a tree object.

 I lost track of this topic; did we decide that this is a good thing
 to do, or unnecessary noise to only cater to a crazy use case?


* nd/exclusion-regression-fix (2016-02-15) 4 commits
 - dir.c: don't exclude whole dir prematurely
 - dir.c: support marking some patterns already matched
 - dir.c: support tracing exclude
 - dir.c: fix match_pathname()

 Another try to add support to the ignore mechanism that lets you
 say "this is excluded" and then later say "oh, no, this part (that
 is a subset of the previous part) is not exlucded".

 Will merge to 'next'.


* nd/worktree-add-B (2016-02-15) 2 commits
 - worktree add -B: do the checkout test before update branch
 - worktree: fix "add -B"

 "git worktree add -B <branchname>" did not work.

 Will merge to 'next'.


* ps/config-error (2016-02-17) 16 commits
 - SQUASH
 - config: rename git_config_set_or_die to git_config_set
 - config: rename git_config_set to git_config_set_gently
 - compat: die when unable to set core.precomposeunicode
 - sequencer: die on config error when saving replay opts
 - init-db: die on config errors when initializing empty repo
 - clone: die on config error in cmd_clone
 - remote: die on config error when manipulating remotes
 - remote: die on config error when setting/adding branches
 - remote: die on config error when setting URL
 - submodule--helper: die on config error when cloning module
 - submodule: die on config error when linking modules
 - branch: die on config error when editing branch description
 - branch: die on config error when unsetting upstream
 - branch: report errors in tracking branch setup
 - config: introduce set_or_die wrappers

 Many codepaths forget to check return value from git_config_set();
 the function is made to die() to make sure we do not proceed when
 setting a configuration variable failed.

 Need to squash the tip two commits into one before moving forward.


* ss/commit-dry-run-resolve-merge-to-no-op (2016-02-17) 1 commit
 - wt-status.c: set commitable bit if there is a meaningful merge.

 "git commit --dry-run" reported "No, no, you cannot commit." in one
 case where "git commit" would have allowed you to commit, and this
 improves it a little bit ("git commit --dry-run --short" still does
 not give you the correct answer, for example).


* tg/git-remote (2016-02-16) 4 commits
 - remote: use remote_is_configured() for add and rename
 - remote: actually check if remote exits
 - remote: simplify remote_is_configured()
 - remote: use parse_config_key

 The internal API to interact with "remote.*" configuration
 variables has been streamlined.

 Will merge to 'next'.


* ls/config-origin (2016-02-17) 3 commits
 - config: add '--show-origin' option to print the origin of a config value
 - config: add 'type' to config_source struct that identifies config type
 - t: do not hide Git's exit code in tests using 'nul_to_q'

--------------------------------------------------
[Stalled]

* ec/annotate-deleted (2015-11-20) 1 commit
 - annotate: skip checking working tree if a revision is provided

 Usability fix for annotate-specific "<file> <rev>" syntax with deleted
 files.

 Waiting for review.


* dg/subtree-rebase-test (2016-01-19) 1 commit
 - contrib/subtree: Add a test for subtree rebase that loses commits

 Reviewed up to v5.
 Will be rerolled.
 ($gmane/284426)


* js/am-3-merge-recursive-direct (2015-10-12) 2 commits
 - am: make a direct call to merge_recursive
 - merge_recursive_options: introduce the "gently" flag

 The merge_recursive_generic() function has been made a bit safer to
 call from inside a process.  "git am -3" was taught to make a direct
 call to the function when falling back to three-way merge.

 Being able to make a direct call would be good in general, but as a
 performance thing, the change needs to be backed up by numbers.

 Needs review.

 I haven't gone through the "gently" change with fine toothed comb;
 I can see that the change avoids calling die(), but I haven't made
 sure that the program states (e.g. what's in the in-core index) are
 adjusted sensibly when it returns to the caller instead of dying,
 or the codepaths that used to die() are free of resource leaks.
 The original code certainly did not care the program states at the
 point of dying exactly because it knew it is going to exit, but now
 they have to care, and they need to be audited.


* dk/gc-more-wo-pack (2016-01-13) 4 commits
 - gc: clean garbage .bitmap files from pack dir
 - t5304: ensure non-garbage files are not deleted
 - t5304: test .bitmap garbage files
 - prepare_packed_git(): find more garbage

 Follow-on to dk/gc-idx-wo-pack topic, to clean up stale
 .bitmap and .keep files.

 Waiting for a reroll.
 ($gmane/284368).


* mg/httpd-tests-update-for-apache-2.4 (2015-04-08) 2 commits
 - t/lib-git-svn: check same httpd module dirs as lib-httpd
 - t/lib-httpd: load mod_unixd

 This is the first two commits in a three-patch series $gmane/266962

 Becoming tired of waiting for a reroll.
 with updated log message ($gmane/268061).
 Will discard.


* jc/diff-b-m (2015-02-23) 5 commits
 . WIPWIP
 . WIP: diff-b-m
 - diffcore-rename: allow easier debugging
 - diffcore-rename.c: add locate_rename_src()
 - diffcore-break: allow debugging

 "git diff -B -M" produced incorrect patch when the postimage of a
 completely rewritten file is similar to the preimage of a removed
 file; such a resulting file must not be expressed as a rename from
 other place.

 The fix in this patch is broken, unfortunately.
 Will discard.

--------------------------------------------------
[Cooking]

* ep/format-printf (2016-02-11) 22 commits
 - wt-status.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - utf8.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - transport-helper.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - trace.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - strbuf.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - remote.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - pkt-line.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - merge-recursive.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - imap-send.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - http-backend.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - fsck.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - daemon.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - config.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - color.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - cache.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - builtin/upload-archive.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - builtin/update-index.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - builtin/receive-pack.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - builtin/index-pack.c: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - argv-array.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - advice.h: use the FORMAT_PRINTF macro to declare the gcc function attribute 'format printf'
 - git-compat-util.h: add the FORMAT_PRINTF macro

 Undecided.


* ew/force-ipv4 (2016-02-12) 1 commit
 - connect & http: support -4 and -6 switches for remote operations

 "git fetch" and friends that make network connections can now be
 told to only use ipv4 (or ipv6).

 Will merge to 'next'.


* jk/lose-name-path (2016-02-12) 5 commits
 - list-objects: pass full pathname to callbacks
 - list-objects: drop name_path entirely
 - list-objects: convert name_path to a strbuf
 - show_object_with_name: simplify by using path_name()
 - http-push: stop using name_path

 The "name_path" API was an attempt to reduce the need to construct
 the full path out of a series of path components while walking a
 tree hierarchy, but over time made less efficient because the path
 needs to be flattened, e.g. to be compared with another path that
 is already flat.  Remove the API and rewrite its users to simplify
 overall code complexity.

 Will merge to 'next'.


* nd/icase (2016-02-15) 12 commits
 - grep.c: reuse "icase" variable
 - diffcore-pickaxe: support case insensitive match on non-ascii
 - diffcore-pickaxe: "share" regex error handling code
 - grep/pcre: support utf-8
 - gettext: add is_utf8_locale()
 - grep/pcre: prepare locale-dependent tables for icase matching
 - grep/icase: avoid kwsset when -F is specified
 - grep/icase: avoid kwsset on literal non-ascii strings
 - test-regex: expose full regcomp() to the command line
 - test-regex: isolate the bug test code
 - grep: break down an "if" stmt in preparation for next changes
 - grep: allow -F -i combination

 "git grep -i" has been taught to fold case in non-ascii locales.

 ($gmane/286137)


* tb/conversion (2016-02-10) 6 commits
  (merged to 'next' on 2016-02-12 at 6faf27b)
 + convert.c: simplify text_stat
 + convert.c: refactor crlf_action
 + convert.c: use text_eol_is_crlf()
 + convert.c: remove input_crlf_action()
 + convert.c: remove unused parameter 'path'
 + t0027: add tests for get_stream_filter()

 Will be rerolled.
 ($gmane/286219)


* sb/submodule-parallel-update (2016-02-13) 7 commits
 - clone: allow an explicit argument for parallel submodule clones
 - submodule update: expose parallelism to the user
 - git submodule update: have a dedicated helper for cloning
 - submodule update: direct error message to stderr
 - fetching submodules: respect `submodule.fetchJobs` config option
 - submodule-config: drop check against NULL
 - submodule-config: keep update strategy around
 (this branch is used by dt/refs-backend-lmdb and sb/submodule-init.)

 A major part of "git submodule update" has been ported to C to take
 advantage of the recently added framework to run download tasks in
 parallel.

 Comments?


* dt/refs-backend-lmdb (2016-02-13) 22 commits
 - refs: tests for lmdb backend
 - refs: add LMDB refs storage backend
 - refs: add register_ref_storage_backends()
 - svn: learn ref-storage argument
 - clone: allow ref storage backend to be set for clone
 - refs: check submodules ref storage config
 - init: allow alternate ref strorage to be set for new repos
 - refs: always handle non-normal refs in files backend
 - refs: resolve symbolic refs first
 - refs: allow log-only updates
 - refs: move duplicate check to common code
 - refs: make lock generic
 - refs: add method to rename refs
 - refs: add methods to init refs db
 - refs: add method for delete_refs
 - refs: add method for initial ref transaction commit
 - refs: add methods for reflog
 - refs: add do_for_each_per_worktree_ref
 - refs: add methods for the ref iterators
 - refs: add methods for misc ref operations
 - refs: add a backend method structure with transaction functions
 - Merge branch 'sb/submodule-parallel-update' into dt/refs-backend-lmdb
 (this branch uses sb/submodule-parallel-update; is tangled with sb/submodule-init.)

 Building on top of a few refs-backend preparatory series, LMDB
 based refs backend has been plugged into the system.

 Will be rerolled.
 ($gmane/285604)


* kn/ref-filter-atom-parsing (2016-02-17) 11 commits
 - ref-filter: introduce objectname_atom_parser()
 - ref-filter: introduce contents_atom_parser()
 - ref-filter: introduce remote_ref_atom_parser()
 - ref-filter: align: introduce long-form syntax
 - ref-filter: introduce align_atom_parser()
 - ref-filter: introduce parse_align_position()
 - ref-filter: introduce color_atom_parser()
 - ref-filter: introduce parsing functions for each valid atom
 - ref-filter: introduce struct used_atom
 - ref-filter: bump 'used_atom' and related code to the top
 - ref-filter: use string_list_split over strbuf_split

 Refactoring of ref-filter's format-parsing code, in preparation
 for "branch --format" and friends.

 Will merge to 'next'.


* ad/cygwin-wants-rename (2015-08-07) 1 commit
 - config.mak.uname: Cygwin needs OBJECT_CREATION_USES_RENAMES

 Will hold.
 ($gmane/275680).


* jc/rerere-multi (2016-02-08) 7 commits
 - rerere: do use multiple variants
 - t4200: rerere a merge with two identical conflicts
 - rerere: allow multiple variants to exist
 - rerere: delay the recording of preimage
 - rerere: handle leftover rr-cache/$ID directory and postimage files
 - rerere: scan $GIT_DIR/rr-cache/$ID when instantiating a rerere_id
 - rerere: split conflict ID further

 "git rerere" can encounter two or more files with the same conflict
 signature that have to be resolved in different ways, but there was
 no way to record these separate resolutions.

 Needs further work on forget/gc.


* jc/merge-drop-old-syntax (2015-04-29) 1 commit
 - merge: drop 'git merge <message> HEAD <commit>' syntax

 Stop supporting "git merge <message> HEAD <commit>" syntax that has
 been deprecated since October 2007.  It has been reported that
 git-gui still uses the deprecated syntax, which needs to be fixed
 before this final step can proceed.
 ($gmane/282594)

--------------------------------------------------
[Discarded]

* dv/http-try-negotiate-at-least-once (2016-02-02) 1 commit
 . remote-curl: don't fall back to Basic auth if we haven't tried Negotiate

 bc/http-empty-auth satisfies the original need that triggered this
 topic better.

Re: What's cooking in git.git (Feb 2016, #05; Wed, 17)

[Jeff King]

On Wed, Feb 17, 2016 at 02:34:08PM -0800, Junio C Hamano wrote:

> * jk/tighten-alloc (2016-02-15) 18 commits
>  - ewah: convert to REALLOC_ARRAY, etc
>  - convert ewah/bitmap code to use xmalloc
>  - diff_populate_gitlink: use a strbuf
>  - transport_anonymize_url: use xstrfmt
>  - git-compat-util: drop mempcpy compat code
>  - sequencer: simplify memory allocation of get_message
>  - test-path-utils: fix normalize_path_copy output buffer size
>  - fetch-pack: simplify add_sought_entry
>  - fast-import: simplify allocation in start_packfile
>  - write_untracked_extension: use FLEX_ALLOC helper
>  - use st_add and st_mult for allocation size computation
>  - convert trivial cases to FLEX_ARRAY macros
>  - use xmallocz to avoid size arithmetic
>  - convert trivial cases to ALLOC_ARRAY
>  - add helpers for allocating flex-array structs
>  - harden REALLOC_ARRAY and xcalloc against size_t overflow
>  - tree-diff: catch integer overflow in combine_diff_path allocation
>  - add helpers for detecting size_t overflow
> 
>  Update various codepaths to avoid manually-counted malloc().
> 
>  Will merge to 'next'.

Please hold off a bit; I have a re-roll coming for this one.

> * nd/dwim-wildcards-as-pathspecs (2016-02-10) 3 commits
>  - get_sha1: don't die() on bogus search strings
>  - check_filename: tighten dwim-wildcard ambiguity
>  - checkout: reorder check_filename conditional
> 
>  "git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a
>  rev, i.e. the object named by the the pathname with wildcard
>  characters in a tree object.
> 
>  I lost track of this topic; did we decide that this is a good thing
>  to do, or unnecessary noise to only cater to a crazy use case?

I think what we ended up with (and what you have queued here) is an
improvement.

I had some question about the tip one, which is a kind-of follow-on, and
makes the error message you get in certain cases a bit less
non-specific. You were "on the fence...but slightly inclined to take"
it.

Even if we drop it, I think the first two patches are an improvement.

-Peff

[1] http://article.gmane.org/gmane.comp.version-control.git/285935

Re: What's cooking in git.git (Feb 2016, #05; Wed, 17)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Feb 17, 2016 at 02:34:08PM -0800, Junio C Hamano wrote:
>
>> * jk/tighten-alloc (2016-02-15) 18 commits
>> ...
> Please hold off a bit; I have a re-roll coming for this one.
>
>> * nd/dwim-wildcards-as-pathspecs (2016-02-10) 3 commits
>> ...
> Even if we drop it, I think the first two patches are an improvement.

Thanks.

whither merge-tree? (was: What's cooking in git.git (Feb 2016, #05; Wed, 17))

[Jeff King]

On Wed, Feb 17, 2016 at 02:34:08PM -0800, Junio C Hamano wrote:

> * jk/merge-tree-merge-blobs (2016-02-16) 1 commit
>  - merge_blobs: use strbuf instead of manually-sized mmfile_t
> 
>  "git merge-tree" (a throw-away demonstration) did not work very
>  well when merging "both sides added a new file at the same path"
>  case.
> 
>  Undecided; we might be better off deleting it altogether.

What do we want to do with this? I think there are basically three
options:

  1. Take the patch you queued above. That's the minimal fix with no
     user-visible changes.

  2. Rip out the weird add/add conflict resolution. This gets rid of the
     buggy code, makes merge-tree more like the rest of git, and I think
     lets us even drop the EMIT_COMMON stuff from xdiff).

     That lets people keep using merge-tree if they have found it useful
     over the years.

  3. Drop merge-tree completely. This deletes even more code, and helps
     the people in (2) realize that it is utterly unmaintained. :)

I think at this point I am waffling between (2) and (3). I did (1) in a
hope that I could avoid looking deeper into the code at all, but now
that I have, I do not think (2) would be so bad. I'm happy to work up a
patch, but won't bother if we think that (3) is viable.

-Peff

Re: whither merge-tree?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

>   2. Rip out the weird add/add conflict resolution. This gets rid of the
>      buggy code, makes merge-tree more like the rest of git, and I think
>      lets us even drop the EMIT_COMMON stuff from xdiff).

That is a nice bonus.

git-merge-resolve (rather, git-merge-one-file) attempts the same
"resolve add/add by taking the common" thing, but it implements it
in quite a different way.

>      That lets people keep using merge-tree if they have found it useful
>      over the years.

>   3. Drop merge-tree completely. This deletes even more code, and helps
>      the people in (2) realize that it is utterly unmaintained. :)
>
> I think at this point I am waffling between (2) and (3). I did (1) in a
> hope that I could avoid looking deeper into the code at all, but now
> that I have, I do not think (2) would be so bad. I'm happy to work up a
> patch, but won't bother if we think that (3) is viable.

Yup, between 2 and 3, 2 would certainly be safer, and I agree that
it is not too bad (I have this feeling that add-add conflict is not
the only funny this code has, though).

Let's wait and see how many "please don't"s we hear, perhaps, before
deciding to go 3.?

Re: whither merge-tree?

[Jeff King]

On Mon, Feb 22, 2016 at 02:45:45PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> >   2. Rip out the weird add/add conflict resolution. This gets rid of the
> >      buggy code, makes merge-tree more like the rest of git, and I think
> >      lets us even drop the EMIT_COMMON stuff from xdiff).
> 
> That is a nice bonus.
> 
> git-merge-resolve (rather, git-merge-one-file) attempts the same
> "resolve add/add by taking the common" thing, but it implements it
> in quite a different way.

I suppose the end result of what merge-tree is trying to do makes sense.
It's definitely a conflict, but we are interested in showing the minimal
content-level conflict. But I think xdl_merge() takes care of that for
us, if we simply feed an empty base. And that is what merge-recursive
does.

I do see that merge-one-file tries create_virtual_base(), which does
some magic with diff. But I'm having trouble conceiving of a case where
that would do something different or useful.

> >      That lets people keep using merge-tree if they have found it useful
> >      over the years.
> 
> >   3. Drop merge-tree completely. This deletes even more code, and helps
> >      the people in (2) realize that it is utterly unmaintained. :)
> >
> > I think at this point I am waffling between (2) and (3). I did (1) in a
> > hope that I could avoid looking deeper into the code at all, but now
> > that I have, I do not think (2) would be so bad. I'm happy to work up a
> > patch, but won't bother if we think that (3) is viable.
> 
> Yup, between 2 and 3, 2 would certainly be safer, and I agree that
> it is not too bad (I have this feeling that add-add conflict is not
> the only funny this code has, though).

Yeah, I do not mind doing 2, but I have no idea what else is lurking,
and I have very little interest in digging into it.

> Let's wait and see how many "please don't"s we hear, perhaps, before
> deciding to go 3.?

I'm guessing we won't see much either way. Even Stefan, the original
reporter, does not seem to actively be using it, but rather relaying a
report.

We'd probably get more response by doing 2 for now, then adding a
deprecation warning to the manpage (and possibly the program itself) for
the next release.

-Peff

Re: whither merge-tree?

[Jeff King]

On Tue, Feb 23, 2016 at 12:02:10AM -0500, Jeff King wrote:

> > git-merge-resolve (rather, git-merge-one-file) attempts the same
> > "resolve add/add by taking the common" thing, but it implements it
> > in quite a different way.
> 
> I suppose the end result of what merge-tree is trying to do makes sense.
> It's definitely a conflict, but we are interested in showing the minimal
> content-level conflict. But I think xdl_merge() takes care of that for
> us, if we simply feed an empty base. And that is what merge-recursive
> does.
> 
> I do see that merge-one-file tries create_virtual_base(), which does
> some magic with diff. But I'm having trouble conceiving of a case where
> that would do something different or useful.

I dug this all the way down to your cb93c19 (merge-one-file: use common
as base, instead of emptiness., 2005-11-09), which states that the goal
is just to get:

	common file contents...
	<<<<<< FILENAME
	version from our branch...
	======
	version from their branch...
	>>>>>> .merge_file_XXXXXX
	more common file contents...

But that seems to be what we produce now. Did all of this simply predate
xdl_merge, and the crappy rcs merge did not bother minimizing the diff?
That certainly seems to be the case in my tests.

If that is the case, I think we can get rid of the complex
create_virtual_base(), as well.

-Peff

Re: whither merge-tree?

[Jeff King]

On Tue, Feb 23, 2016 at 12:14:02AM -0500, Jeff King wrote:

> I dug this all the way down to your cb93c19 (merge-one-file: use common
> as base, instead of emptiness., 2005-11-09), which states that the goal
> is just to get:
> 
> 	common file contents...
> 	<<<<<< FILENAME
> 	version from our branch...
> 	======
> 	version from their branch...
> 	>>>>>> .merge_file_XXXXXX
> 	more common file contents...
> 
> But that seems to be what we produce now. Did all of this simply predate
> xdl_merge, and the crappy rcs merge did not bother minimizing the diff?
> That certainly seems to be the case in my tests.
> 
> If that is the case, I think we can get rid of the complex
> create_virtual_base(), as well.

So here is what I would propose:

  [1/3]: merge-one-file: use empty blob for add/add base
  [2/3]: merge-tree: drop generate_common strategy
  [3/3]: xdiff: drop XDL_EMIT_COMMON

I briefly wondered if there were any bugs in merge-one-file around this
"no newline at end of file" issue. But there shouldn't be. It generates
the common file by applying the diff to the first file with "--no-add",
which should do the right thing, I think.

I stopped short of dropping the create_virtual_base function in the
first patch, for reasons explained there. But if we were to do so, I
suspect we could deprecated and eventually drop "apply --no-add", too.

-Peff

[PATCH 1/3] merge-one-file: use empty blob for add/add base

[Jeff King]

When we see an add/add conflict on a file, we generate the
conflicted content by doing a 3-way merge with a "virtual"
base consisting of the common lines of the two sides. This
strategy dates back to cb93c19 (merge-one-file: use common
as base, instead of emptiness., 2005-11-09).

Back then, the next step was to call rcs merge to generate
the 3-way conflicts. Using the virtual base produced much
better results, as rcs merge does not attempt to minimize
the hunks. As a result, you'd get a conflict with the
entirety of the files on either side.

Since then, though, we've switched to using git-merge-file,
which uses xdiff's "zealous" merge. This will find the
minimal hunks even with just the simple, empty base.

Let's switch to using that empty base. It's simpler, more
efficient, and reduces our dependencies (we no longer need a
working diff binary). It's also how the merge-recursive
strategy handles this same case.

We can almost get rid of git-sh-setup's create_virtual_base,
but we don't here, for two reasons:

  1. The functions in git-sh-setup are part of our public
     interface, so it's possible somebody is depending on
     it. We'd at least need to deprecate it first.

  2. It's also used by mergetool's p4merge driver. It's
     unknown whether its 3-way merge is as capable as git's;
     if not, then it is benefiting from the function.

Signed-off-by: Jeff King <peff@peff.net>
---
 git-merge-one-file.sh | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index cdc02af..424b034 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -120,8 +120,7 @@ case "${1:-.}${2:-.}${3:-.}" in
 	case "$1" in
 	'')
 		echo "Added $4 in both, but differently."
-		orig=$(git-unpack-file $2)
-		create_virtual_base "$orig" "$src2"
+		orig=$(git-unpack-file e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
 		;;
 	*)
 		echo "Auto-merging $4"
-- 
2.7.2.645.g4e1306c

[PATCH 2/3] merge-tree: drop generate_common strategy

[Jeff King]

When merge_blobs sees an add/add conflict, it tries to
create a virtual base object for the 3-way merge that
consists of the common lines of each file. It inherited this
strategy from merge-one-file in 0c79938 (Improved three-way
blob merging code, 2006-06-28), and the point is to minimize
the size of the conflict hunks. That commit talks about "if
libxdiff were to ever grow a compatible three-way merge, it
could probably be directly plugged in".

That has long since happened. So as with merge-one-file in
the previous commit, this extra step is no longer necessary.
Our 3-way merge code is smart enough to do the minimizing
itself if we simply feed it an empty base, which is what the
more modern merge-recursive strategy already does.

Not only does this let us drop some code, but it removes an
overflow bug in generate_common_file(). We allocate a buffer
as large as the smallest of the two blobs, under the
assumption that there cannot be more common content than
what is in the smaller blob. However, xdiff may feed us
more: if neither file ends in a newline, it feeds us the
"\nNo newline at end of file" marker as common content, and
we write it into the output. If the differences between the
files are small than that string, we overflow the output
buffer.  This patch solves it by simply dropping the buggy
code entirely.

Signed-off-by: Jeff King <peff@peff.net>
---
 merge-blobs.c | 38 ++------------------------------------
 1 file changed, 2 insertions(+), 36 deletions(-)

diff --git a/merge-blobs.c b/merge-blobs.c
index ddca601..9b6eac2 100644
--- a/merge-blobs.c
+++ b/merge-blobs.c
@@ -48,40 +48,6 @@ static void *three_way_filemerge(const char *path, mmfile_t *base, mmfile_t *our
 	return res.ptr;
 }
 
-static int common_outf(void *priv_, mmbuffer_t *mb, int nbuf)
-{
-	int i;
-	mmfile_t *dst = priv_;
-
-	for (i = 0; i < nbuf; i++) {
-		memcpy(dst->ptr + dst->size, mb[i].ptr, mb[i].size);
-		dst->size += mb[i].size;
-	}
-	return 0;
-}
-
-static int generate_common_file(mmfile_t *res, mmfile_t *f1, mmfile_t *f2)
-{
-	unsigned long size = f1->size < f2->size ? f1->size : f2->size;
-	void *ptr = xmalloc(size);
-	xpparam_t xpp;
-	xdemitconf_t xecfg;
-	xdemitcb_t ecb;
-
-	memset(&xpp, 0, sizeof(xpp));
-	xpp.flags = 0;
-	memset(&xecfg, 0, sizeof(xecfg));
-	xecfg.ctxlen = 3;
-	xecfg.flags = XDL_EMIT_COMMON;
-	ecb.outf = common_outf;
-
-	res->ptr = ptr;
-	res->size = 0;
-
-	ecb.priv = res;
-	return xdi_diff(f1, f2, &xpp, &xecfg, &ecb);
-}
-
 void *merge_blobs(const char *path, struct blob *base, struct blob *our, struct blob *their, unsigned long *size)
 {
 	void *res = NULL;
@@ -112,8 +78,8 @@ void *merge_blobs(const char *path, struct blob *base, struct blob *our, struct
 		if (fill_mmfile_blob(&common, base) < 0)
 			goto out_free_f2_f1;
 	} else {
-		if (generate_common_file(&common, &f1, &f2) < 0)
-			goto out_free_f2_f1;
+		common.ptr = xstrdup("");
+		common.size = 0;
 	}
 	res = three_way_filemerge(path, &common, &f1, &f2, size);
 	free_mmfile(&common);
-- 
2.7.2.645.g4e1306c

[PATCH 3/3] xdiff: drop XDL_EMIT_COMMON

[Jeff King]

There are no more callers that use this mode, and none
likely to be added (as our xdl_merge() eliminates the common
use of it for generating 3-way merge bases).

This is effectively a revert of a9ed376 (xdiff: generate
"anti-diffs" aka what is common to two files, 2006-06-28),
though of course trying to revert that ancient commit
directly produces many textual conflicts.

Signed-off-by: Jeff King <peff@peff.net>
---
 xdiff/xdiff.h |  1 -
 xdiff/xemit.c | 18 ------------------
 2 files changed, 19 deletions(-)

diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index c033991..4fb7e79 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -42,7 +42,6 @@ extern "C" {
 #define XDF_IGNORE_BLANK_LINES (1 << 7)
 
 #define XDL_EMIT_FUNCNAMES (1 << 0)
-#define XDL_EMIT_COMMON (1 << 1)
 #define XDL_EMIT_FUNCCONTEXT (1 << 2)
 
 #define XDL_MMB_READONLY (1 << 0)
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 4266ada..993724b 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -120,21 +120,6 @@ static long def_ff(const char *rec, long len, char *buf, long sz, void *priv)
 	return -1;
 }
 
-static int xdl_emit_common(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
-                           xdemitconf_t const *xecfg) {
-	xdfile_t *xdf = &xe->xdf2;
-	const char *rchg = xdf->rchg;
-	long ix;
-
-	for (ix = 0; ix < xdf->nrec; ix++) {
-		if (rchg[ix])
-			continue;
-		if (xdl_emit_record(xdf, ix, "", ecb))
-			return -1;
-	}
-	return 0;
-}
-
 struct func_line {
 	long len;
 	char buf[80];
@@ -170,9 +155,6 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
 	long funclineprev = -1;
 	struct func_line func_line = { 0 };
 
-	if (xecfg->flags & XDL_EMIT_COMMON)
-		return xdl_emit_common(xe, xscr, ecb, xecfg);
-
 	for (xch = xscr; xch; xch = xche->next) {
 		xche = xdl_get_hunk(&xch, xecfg);
 		if (!xch)
-- 
2.7.2.645.g4e1306c

Re: whither merge-tree?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Tue, Feb 23, 2016 at 12:14:02AM -0500, Jeff King wrote:
>
>> I dug this all the way down to your cb93c19 (merge-one-file: use common
>> as base, instead of emptiness., 2005-11-09), which states that the goal
>> is just to get:
>> 
>> 	common file contents...
>> 	<<<<<< FILENAME
>> 	version from our branch...
>> 	======
>> 	version from their branch...
>> 	>>>>>> .merge_file_XXXXXX
>> 	more common file contents...
>> 
>> But that seems to be what we produce now. Did all of this simply predate
>> xdl_merge, and the crappy rcs merge did not bother minimizing the diff?
>> That certainly seems to be the case in my tests.
>> 
>> If that is the case, I think we can get rid of the complex
>> create_virtual_base(), as well.
>
> So here is what I would propose:
>
>   [1/3]: merge-one-file: use empty blob for add/add base
>   [2/3]: merge-tree: drop generate_common strategy
>   [3/3]: xdiff: drop XDL_EMIT_COMMON
>
> I briefly wondered if there were any bugs in merge-one-file around this
> "no newline at end of file" issue. But there shouldn't be. It generates
> the common file by applying the diff to the first file with "--no-add",
> which should do the right thing, I think.
>
> I stopped short of dropping the create_virtual_base function in the
> first patch, for reasons explained there. But if we were to do so, I
> suspect we could deprecated and eventually drop "apply --no-add", too.

Thanks.  I think the "virtual" stuff started its life outside
sh-setup but later was moved there for p4merge.  The log message for
4549162e (mergetools/p4merge: create a base if none available,
2013-03-13) seems to indicate that using an empty file does not work
well over there as you suspected, so unfortunately we cannot lose it
just yet.

Re: whither merge-tree?

[Jeff King]

On Mon, Feb 22, 2016 at 10:35:34PM -0800, Junio C Hamano wrote:

> > I stopped short of dropping the create_virtual_base function in the
> > first patch, for reasons explained there. But if we were to do so, I
> > suspect we could deprecated and eventually drop "apply --no-add", too.
> 
> Thanks.  I think the "virtual" stuff started its life outside
> sh-setup but later was moved there for p4merge.  The log message for
> 4549162e (mergetools/p4merge: create a base if none available,
> 2013-03-13) seems to indicate that using an empty file does not work
> well over there as you suspected, so unfortunately we cannot lose it
> just yet.

Oh, indeed. I did find that commit in my git-blaming, but failed to
actually read it carefully. :)

With that, yeah, I agree that we cannot drop the virtual-base thing, and
my 3 patches are fine as-is.

-Peff

Re: whither merge-tree?

[Stefan Frühwirth]

On 23.02.2016 at 06:02 Jeff King wrote:
>> Let's wait and see how many "please don't"s we hear, perhaps, before
>> deciding to go 3.?
>
> I'm guessing we won't see much either way. Even Stefan, the original
> reporter, does not seem to actively be using it, but rather relaying a
> report.

I _am_ actively using it. Maybe I was unclear on that topic. I'm in 
favour of keeping it, because this means I don't have to rewrite Chris' 
Code in order to be able to use the Python library that uses merge-tree 
(Acidfs). But as a sensible human being I want what's best in the long 
run. I leave that up to you as I have no way of assessing that.

So that's a "please don't" leave the code as-is but provide a 
(transitional) solution that fixes the reported bug and has the best 
chances of not causing any more headaches :)

> We'd probably get more response by doing 2 for now, then adding a
> deprecation warning to the manpage (and possibly the program itself) for
> the next release.

A deprecation warning would be very welcome.

Thanks,
Stefan

Re: whither merge-tree?

[Johannes Schindelin]

Hi Peff,

On Tue, 23 Feb 2016, Jeff King wrote:

> On Mon, Feb 22, 2016 at 02:45:45PM -0800, Junio C Hamano wrote:
> 
> > Jeff King <peff@peff.net> writes:
> > 
> > >   3. Drop merge-tree completely. This deletes even more code, and
> > >   helps the people in (2) realize that it is utterly unmaintained.
> > >   :)
> >
> > Let's wait and see how many "please don't"s we hear, perhaps, before
> > deciding to go 3.?
> 
> I'm guessing we won't see much either way.

We could encourage more voices by issuing a warning when merge-tree is
called, e.g.:

	warning: merge-tree is unsupported (please contact
		 git@vger.kernel.org if you use it actively)

Ciao,
Dscho

Re: whither merge-tree?

[Duy Nguyen]

On Tue, Feb 23, 2016 at 7:36 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> We could encourage more voices by issuing a warning when merge-tree is
> called, e.g.:
>
>         warning: merge-tree is unsupported (please contact
>                  git@vger.kernel.org if you use it actively)

Maybe motivate them to reach git@vger by s/use it actively/do not want it gone/.
-- 
Duy

Re: whither merge-tree?

[Dennis Kaarsemaker]

On di, 2016-02-23 at 10:49 +0100, Stefan Frühwirth wrote:
> On 23.02.2016 at 06:02 Jeff King wrote:
> > > Let's wait and see how many "please don't"s we hear, perhaps,
> > > before
> > > deciding to go 3.?
> > 
> > I'm guessing we won't see much either way. Even Stefan, the
> > original
> > reporter, does not seem to actively be using it, but rather
> > relaying a
> > report.
> 
> I _am_ actively using it. Maybe I was unclear on that topic. I'm in 
> favour of keeping it, because this means I don't have to rewrite
> Chris' 
> Code in order to be able to use the Python library that uses merge-
> tree 
> (Acidfs). But as a sensible human being I want what's best in the
> long 
> run. I leave that up to you as I have no way of assessing that.
> 
> So that's a "please don't" leave the code as-is but provide a 
> (transitional) solution that fixes the reported bug and has the best 
> chances of not causing any more headaches :)

I am also actively using it. It's the only way (I know of) of trying to
preview a merge result without attempting the actual merge, which is
useful in some of my scripts.

-- 
Dennis Kaarsemaker
www.kaarsemaker.net

Re: whither merge-tree?

[Jeff King]

On Wed, Feb 24, 2016 at 08:28:59AM +0100, Dennis Kaarsemaker wrote:

> > So that's a "please don't" leave the code as-is but provide a 
> > (transitional) solution that fixes the reported bug and has the best 
> > chances of not causing any more headaches :)
> 
> I am also actively using it. It's the only way (I know of) of trying to
> preview a merge result without attempting the actual merge, which is
> useful in some of my scripts.

OK. I guess we can live with the series I posted earlier (to simplify
the add/add behavior and fix the overflow), and leave it in place.

I _do_ think it's a useful concept, and there isn't something quite like
it in git right now. At one point I contemplated teaching unpack-trees
to do the content-level merges too, so you could do this via read-tree,
but I didn't ever polish it[1]. So I am sympathetic to the goal, and
there's not another way to do it as efficiently.

And now I feel like both of you have been warned that the code might be
crufty. :)

I'm not sure what we should do about warning others.  Since people are
using it, I don't want to put a deprecation warning. It's not "this will
be removed in the next version" anymore, but "watch out, this might be
crufty". I guess that can go in the manpage, but I'm not quite sure how
to word it.

-Peff

[1] It looks like my patch has been collecting dust since 2011:

      git://github.com/peff/git.git jk/read-tree-content-merge-wip

    It's been rebased along with all of my other topics since then, but
    otherwise I have no clue if it works or even compiles (it's not part
    of my day-to-day build). Anyone is welcome to use it as a base if
    they want to pursue it.

Re: whither merge-tree?

[Jeff King]

On Tue, Feb 23, 2016 at 10:49:34AM +0100, Stefan Frühwirth wrote:

> On 23.02.2016 at 06:02 Jeff King wrote:
> >>Let's wait and see how many "please don't"s we hear, perhaps, before
> >>deciding to go 3.?
> >
> >I'm guessing we won't see much either way. Even Stefan, the original
> >reporter, does not seem to actively be using it, but rather relaying a
> >report.
> 
> I _am_ actively using it. Maybe I was unclear on that topic. I'm in favour
> of keeping it, because this means I don't have to rewrite Chris' Code in
> order to be able to use the Python library that uses merge-tree (Acidfs).
> But as a sensible human being I want what's best in the long run. I leave
> that up to you as I have no way of assessing that.

Ah, sorry for the confusion. I had thought you were just relaying bugs
on behalf of acidfs folks, but it makes sense that you are using it
indirectly through the library.

> So that's a "please don't" leave the code as-is but provide a (transitional)
> solution that fixes the reported bug and has the best chances of not causing
> any more headaches :)

I think the series I posted does what you want, then, and we can stop
short of deprecating for now.

-Peff