Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)
Eric Sunshinewrites: > On Wed, Apr 25, 2018 at 4:37 AM, Junio C Hamano wrote: >> * tg/worktree-add-existing-branch (2018-04-25) 4 commits >> - worktree: teach "add" to check out existing branches >> - worktree: factor out dwim_branch function >> - worktree: improve message when creating a new worktree >> - worktree: remove extra members from struct add_opts >> >> "git worktree add" learned to check out an existing branch. >> >> Is this ready for 'next'? > > I just gave v9 (which you have queued) a final full review and found > it satisfactory (and gave my Reviewed-by:), so yes, it seems ready for > 'next'. Thanks, both.
Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)
On Wed, Apr 25, 2018 at 4:37 AM, Junio C Hamanowrote: > * tg/worktree-add-existing-branch (2018-04-25) 4 commits > - worktree: teach "add" to check out existing branches > - worktree: factor out dwim_branch function > - worktree: improve message when creating a new worktree > - worktree: remove extra members from struct add_opts > > "git worktree add" learned to check out an existing branch. > > Is this ready for 'next'? I just gave v9 (which you have queued) a final full review and found it satisfactory (and gave my Reviewed-by:), so yes, it seems ready for 'next'. Thanks.
Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)
Hi, On Thu, 26 Apr 2018, Derrick Stolee wrote: > On 4/25/2018 1:43 PM, Brandon Williams wrote: > > On 04/25, Ævar Arnfjörð Bjarmason wrote: > > > > * bw/protocol-v2 (2018-03-15) 35 commits > > > > (merged to 'next' on 2018-04-11 at 23ee234a2c) [... snip ...] > > > > (this branch is used by bw/server-options.) > > > > > > > > The beginning of the next-gen transfer protocol. > > > > > > > > Will cook in 'next'. > > > > > > With a month & 10 days of no updates & this looking stable it would > > > be great to have it in master sooner than later to build on top of > > > it in the 2.18 window. > > > > I personally think that this series is ready to graduate to master but > > I mentioned to Junio off-list that it might be a good idea to wait > > until it has undergone a little more stress testing. We've been in > > the process of trying to get this rolled out to our internal server > > but due to a few roadblocks and people being out of the office its > > taken a bit longer than I would have liked to get it up and running. > > I'm hoping in another few days/a week I'll have some more data on live > > traffic. At that point I think I'll be more convinced that it will be > > safe to merge it. > > > > I may be overly cautions but I'm hoping that we can get this right > > without needing to do another protocol version bump for a very long > > time. Technically using v2 is hidden behind an "experimental" config > > flag so we should still be able to tweak it after the fact if we > > absolutely needed to, but I'd like to avoid that if necessary. > > There's no testing better than production. I think if we have an > opportunity to test with realistic traffic, we should take advantage. > > But I also agree that this series looks stable. > > I realize it's hard to communicate both "this series is ready to merge" and "I > appreciate your caution." To add to Stolee's comment: in our (day job) team, we are huge fans of "Feature Flags". We blog plenty about it, GitHub uses it in their Scientist approach, and even here in the Git project, we managed to use the paradigm: remember the transition from the scripted version of `difftool` to the builtin version? That was also done via a Feature Flag. In the same vein, I would treat your config setting as a Feature Flag, and I would be very much in favor of having the code in production, with that feature flag defaulting to "off", and with a description that tells people very clearly that not only the flag is experimental, but that we might need to change the protocol, still, before v2 goes final. I would then add an entry to Git for Windows' installer's "Experimental Options" section, to give it a bit more exposure (mainly to verify that the v2 client <-> v1 server connection works flawlessly), also as opt-in. How does that sound? Ciao, Dscho
Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)
On Wed, Apr 25, 2018 at 10:37 AM, Junio C Hamanowrote: > * nd/pack-objects-pack-struct (2018-04-16) 15 commits > ... > > "git pack-objects" needs to allocate tons of "struct object_entry" > while doing its work, and shrinking its size helps the performance > quite a bit. > > What's the doneness of this thing? The interdiff since previous > rounds looked reasonable, but I didn't see this round otherwise > scrutinized by reviewers. The numbers given in the commit near the > tip do look impressive, though ;-) I think it's ok to move it to next, though I'd prefer to move it to master just right after a release so it gets tested for a whole release cycle. This also gives Jeff a chance to check it after he's back (if he wants to). > * nd/repack-keep-pack (2018-04-16) 7 commits > ... > > "git gc" in a large repository takes a lot of time as it considers > to repack all objects into one pack by default. The command has > been taught to pretend as if the largest existing packfile is > marked with ".keep" so that it is left untouched while objects in > other packs and loose ones are repacked. > > What's the doneness of this thing? The interdiff since the earlier > one looked reasonable, but I didn't see this round otherwise > scrutinized by reviewers. This one should be safer than the previous one. I think it's ok to move to next. Anyway I'll re-read these two series this weekend to see if I could spot anything new. -- Duy
Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)
On 4/25/2018 1:43 PM, Brandon Williams wrote: On 04/25, Ævar Arnfjörð Bjarmason wrote: * bw/protocol-v2 (2018-03-15) 35 commits (merged to 'next' on 2018-04-11 at 23ee234a2c) + remote-curl: don't request v2 when pushing + remote-curl: implement stateless-connect command + http: eliminate "# service" line when using protocol v2 + http: don't always add Git-Protocol header + http: allow providing extra headers for http requests + remote-curl: store the protocol version the server responded with + remote-curl: create copy of the service name + pkt-line: add packet_buf_write_len function + transport-helper: introduce stateless-connect + transport-helper: refactor process_connect_service + transport-helper: remove name parameter + connect: don't request v2 when pushing + connect: refactor git_connect to only get the protocol version once + fetch-pack: support shallow requests + fetch-pack: perform a fetch using v2 + upload-pack: introduce fetch server command + push: pass ref prefixes when pushing + fetch: pass ref prefixes when fetching + ls-remote: pass ref prefixes when requesting a remote's refs + transport: convert transport_get_remote_refs to take a list of ref prefixes + transport: convert get_refs_list to take a list of ref prefixes + connect: request remote refs using v2 + ls-refs: introduce ls-refs server command + serve: introduce git-serve + test-pkt-line: introduce a packet-line test helper + protocol: introduce enum protocol_version value protocol_v2 + transport: store protocol version + connect: discover protocol version outside of get_remote_heads + connect: convert get_remote_heads to use struct packet_reader + transport: use get_refs_via_connect to get refs + upload-pack: factor out processing lines + upload-pack: convert to a builtin + pkt-line: add delim packet support + pkt-line: allow peeking a packet line without consuming it + pkt-line: introduce packet_read_with_status (this branch is used by bw/server-options.) The beginning of the next-gen transfer protocol. Will cook in 'next'. With a month & 10 days of no updates & this looking stable it would be great to have it in master sooner than later to build on top of it in the 2.18 window. I personally think that this series is ready to graduate to master but I mentioned to Junio off-list that it might be a good idea to wait until it has undergone a little more stress testing. We've been in the process of trying to get this rolled out to our internal server but due to a few roadblocks and people being out of the office its taken a bit longer than I would have liked to get it up and running. I'm hoping in another few days/a week I'll have some more data on live traffic. At that point I think I'll be more convinced that it will be safe to merge it. I may be overly cautions but I'm hoping that we can get this right without needing to do another protocol version bump for a very long time. Technically using v2 is hidden behind an "experimental" config flag so we should still be able to tweak it after the fact if we absolutely needed to, but I'd like to avoid that if necessary. There's no testing better than production. I think if we have an opportunity to test with realistic traffic, we should take advantage. But I also agree that this series looks stable. I realize it's hard to communicate both "this series is ready to merge" and "I appreciate your caution." Thanks, -Stolee
Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)
Elijah Newrenwrites: > On Wed, Apr 25, 2018 at 1:37 AM, Junio C Hamano wrote: > >> * en/unpack-trees-split-index-fix (2018-04-24) 1 commit >> * en/rename-directory-detection-reboot (2018-04-25) 36 commits > ... > Would you still like a re-roll? Not really. We can just merge them together and move on.
Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)
On Wed, Apr 25, 2018 at 05:37:52PM +0900, Junio C Hamano wrote: > * bc/object-id (2018-04-24) 41 commits > - merge-one-file: compute empty blob object ID > - add--interactive: compute the empty tree value > - Update shell scripts to compute empty tree object ID > - sha1_file: only expose empty object constants through git_hash_algo > - dir: use the_hash_algo for empty blob object ID > - sequencer: use the_hash_algo for empty tree object ID > - cache-tree: use is_empty_tree_oid > - sha1_file: convert cached object code to struct object_id > - builtin/reset: convert use of EMPTY_TREE_SHA1_BIN > - builtin/receive-pack: convert one use of EMPTY_TREE_SHA1_HEX > - wt-status: convert two uses of EMPTY_TREE_SHA1_HEX > - submodule: convert several uses of EMPTY_TREE_SHA1_HEX > - sequencer: convert one use of EMPTY_TREE_SHA1_HEX > - merge: convert empty tree constant to the_hash_algo > - builtin/merge: switch tree functions to use object_id > - builtin/am: convert uses of EMPTY_TREE_SHA1_BIN to the_hash_algo > - builtin/receive-pack: avoid hard-coded constants for push certs > - diff: specify abbreviation size in terms of the_hash_algo > - upload-pack: replace use of several hard-coded constants > - revision: replace use of hard-coded constants > - http: eliminate hard-coded constants > - dir: convert struct untracked_cache_dir to object_id > - commit: convert uses of get_sha1_hex to get_oid_hex > - index-pack: abstract away hash function constant > - pack-redundant: convert linked lists to use struct object_id > - Update struct index_state to use struct object_id > - split-index: convert struct split_index to object_id > - submodule-config: convert structures to object_id > - fsck: convert static functions to struct object_id > - tree-walk: convert get_tree_entry_follow_symlinks to object_id > - tree-walk: avoid hard-coded 20 constant > - pack-redundant: abstract away hash algorithm > - pack-objects: abstract away hash algorithm > - packfile: abstract away hash constant values > - packfile: convert find_pack_entry to object_id > - sha1_file: convert freshen functions to object_id > - packfile: convert has_sha1_pack to object_id > - packfile: remove unused member from struct pack_entry > - Remove unused member in struct object_context > - server-info: remove unused members from struct pack_info > - cache: add a function to read an object ID from a buffer > > Conversion from uchar[20] to struct object_id continues. I do plan to reroll this, and if you want to forge my sign-off on the patch I missed in the mean time, please do. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)
On 04/25, Ævar Arnfjörð Bjarmason wrote: > > * bw/protocol-v2 (2018-03-15) 35 commits > > (merged to 'next' on 2018-04-11 at 23ee234a2c) > > + remote-curl: don't request v2 when pushing > > + remote-curl: implement stateless-connect command > > + http: eliminate "# service" line when using protocol v2 > > + http: don't always add Git-Protocol header > > + http: allow providing extra headers for http requests > > + remote-curl: store the protocol version the server responded with > > + remote-curl: create copy of the service name > > + pkt-line: add packet_buf_write_len function > > + transport-helper: introduce stateless-connect > > + transport-helper: refactor process_connect_service > > + transport-helper: remove name parameter > > + connect: don't request v2 when pushing > > + connect: refactor git_connect to only get the protocol version once > > + fetch-pack: support shallow requests > > + fetch-pack: perform a fetch using v2 > > + upload-pack: introduce fetch server command > > + push: pass ref prefixes when pushing > > + fetch: pass ref prefixes when fetching > > + ls-remote: pass ref prefixes when requesting a remote's refs > > + transport: convert transport_get_remote_refs to take a list of ref > > prefixes > > + transport: convert get_refs_list to take a list of ref prefixes > > + connect: request remote refs using v2 > > + ls-refs: introduce ls-refs server command > > + serve: introduce git-serve > > + test-pkt-line: introduce a packet-line test helper > > + protocol: introduce enum protocol_version value protocol_v2 > > + transport: store protocol version > > + connect: discover protocol version outside of get_remote_heads > > + connect: convert get_remote_heads to use struct packet_reader > > + transport: use get_refs_via_connect to get refs > > + upload-pack: factor out processing lines > > + upload-pack: convert to a builtin > > + pkt-line: add delim packet support > > + pkt-line: allow peeking a packet line without consuming it > > + pkt-line: introduce packet_read_with_status > > (this branch is used by bw/server-options.) > > > > The beginning of the next-gen transfer protocol. > > > > Will cook in 'next'. > > With a month & 10 days of no updates & this looking stable it would be > great to have it in master sooner than later to build on top of it in > the 2.18 window. I personally think that this series is ready to graduate to master but I mentioned to Junio off-list that it might be a good idea to wait until it has undergone a little more stress testing. We've been in the process of trying to get this rolled out to our internal server but due to a few roadblocks and people being out of the office its taken a bit longer than I would have liked to get it up and running. I'm hoping in another few days/a week I'll have some more data on live traffic. At that point I think I'll be more convinced that it will be safe to merge it. I may be overly cautions but I'm hoping that we can get this right without needing to do another protocol version bump for a very long time. Technically using v2 is hidden behind an "experimental" config flag so we should still be able to tweak it after the fact if we absolutely needed to, but I'd like to avoid that if necessary. -- Brandon Williams
Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)
Hi Junio, On Wed, Apr 25, 2018 at 1:37 AM, Junio C Hamanowrote: > * en/unpack-trees-split-index-fix (2018-04-24) 1 commit > - unpack_trees: fix breakage when o->src_index != o->dst_index > > The split-index feature had a long-standing and dormant bug in > certain use of the in-core merge machinery, which has been fixed. > > Will merge to 'next'. This topic... > * en/rename-directory-detection-reboot (2018-04-25) 36 commits > > Reboot of an attempt to detect wholesale directory renames and use > it while merging. > > Expecting a reroll. > cf. ...is the fix to the issue mentioned in this email you reference. The various revisions of the en/unpack-trees-split-index-fix patches were even posted as a response to the parent of the email you reference (which I thought made sense since the parent was the report of the issue; sorry if that confused things). Would you still like a re-roll? If you do, the _only_ thing I'll change is a minor typo in the commit message of 948d8a6f0895 ("t6046: testcases checking whether updates can be skipped in a merge", 2018-04-19), doing a simple s/year/years/. There aren't any remaining outstanding issues with this series I know of, and I've tested everything I can think of to test.
js/rebase-recreate-merge, was Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)
Hi Junio, On Wed, 25 Apr 2018, Junio C Hamano wrote: > * js/rebase-recreate-merge (2018-04-24) 16 commits > - rebase -i --rebase-merges: add a section to the man page > - rebase -i: introduce --rebase-merges=[no-]rebase-cousins > - pull: accept --rebase=merges to recreate the branch topology > - rebase --rebase-merges: avoid "empty merges" > - sequencer: handle post-rewrite for merge commands > - sequencer: make refs generated by the `label` command worktree-local > - rebase --rebase-merges: add test for --keep-empty > - rebase: introduce the --rebase-merges option > - rebase-helper --make-script: introduce a flag to rebase merges > - sequencer: fast-forward `merge` commands, if possible > - sequencer: introduce the `merge` command > - git-rebase--interactive: clarify arguments > - sequencer: offer helpful advice when a command was rescheduled > - sequencer: refactor how original todo list lines are accessed > - sequencer: make rearrange_squash() a bit more obvious > - sequencer: avoid using errno clobbered by rollback_lock_file() > > "git rebase" learned "--rebase-merges" to transplant the whole > topology of commit graph elsewhere. > > Was on hold. What's the donness of this thing? > cf. >There was enough in limbo that it required a v9, and in hindsight that was a good thing, too, as I prefered to resolve the merge conflicts with Phillip's patch series myself rather than have you do it. But I hope v9 is good enough for `master`, even if I agree that it would be safer to go through `next`. This patch series, along with the upcoming `sequencer-and-root-commits` one, is a crucial building block for the two GSoC projects to convert rebase and rebase -i into builtins. Ciao, Dscho
Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)
On Wed, Apr 25 2018, Junio C. Hamano wrote: > THe command line completion (in contrib/) has been taught that "git > * js/colored-push-errors (2018-04-24) 4 commits > - config: document the settings to colorize push errors/hints > - push: test to verify that push errors are colored > - push: colorize errors > - color: introduce support for colorizing stderr > > Error messages from "git push" can be painted for more visibility. This is a really good UI improvement. Just got around to looking at this now, looks good! > * sb/diff-color-move-more (2018-04-25) 7 commits > - diff.c: add --color-moved-ignore-space-delta option > - diff.c: decouple white space treatment from move detection algorithm > - diff.c: add a blocks mode for moved code detection > - diff.c: adjust hash function signature to match hashmap expectation > - diff.c: do not pass diff options as keydata to hashmap > - xdiff/xdiffi.c: remove unneeded function declarations > - xdiff/xdiff.h: remove unused flags > > "git diff --color-moved" feature has further been tweaked. I hadn't had time to look at https://public-inbox.org/git/20180403210536.33798-1-sbel...@google.com/ before. Looks good to me, great to have the new "blocks" mode. > * ab/simplify-perl-makefile (2018-04-19) 2 commits > (merged to 'next' on 2018-04-25 at 906cf21682) > + Makefile: mark perllibdir as a .PHONY target > (merged to 'next' on 2018-04-17 at 4448756934) > + perl: fix installing modules from contrib > > Recent simplification of build procedure forgot a bit of tweak to > the build procedure of contrib/mw-to-git/ > > Will merge to 'master'. Thanks to Christian Hesse for fixing up my mess. > * nd/pack-objects-pack-struct (2018-04-16) 15 commits > - ci: exercise the whole test suite with uncommon code in pack-objects > - pack-objects: reorder members to shrink struct object_entry > - pack-objects: shrink delta_size field in struct object_entry > - pack-objects: shrink size field in struct object_entry > - pack-objects: clarify the use of object_entry::size > - pack-objects: don't check size when the object is bad > - pack-objects: shrink z_delta_size field in struct object_entry > - pack-objects: refer to delta objects by index instead of pointer > - pack-objects: move in_pack out of struct object_entry > - pack-objects: move in_pack_pos out of struct object_entry > - pack-objects: use bitfield for object_entry::depth > - pack-objects: use bitfield for object_entry::dfs_state > - pack-objects: turn type and in_pack_type to bitfields > - pack-objects: a bit of document about struct object_entry > - read-cache.c: make $GIT_TEST_SPLIT_INDEX boolean > > "git pack-objects" needs to allocate tons of "struct object_entry" > while doing its work, and shrinking its size helps the performance > quite a bit. > > What's the doneness of this thing? The interdiff since previous > rounds looked reasonable, but I didn't see this round otherwise > scrutinized by reviewers. The numbers given in the commit near the > tip do look impressive, though ;-) > > * nd/repack-keep-pack (2018-04-16) 7 commits > - pack-objects: show some progress when counting kept objects > - gc --auto: exclude base pack if not enough mem to "repack -ad" > - gc: handle a corner case in gc.bigPackThreshold > - gc: add gc.bigPackThreshold config > - gc: add --keep-largest-pack option > - repack: add --keep-pack option > - t7700: have closing quote of a test at the beginning of line > > "git gc" in a large repository takes a lot of time as it considers > to repack all objects into one pack by default. The command has > been taught to pretend as if the largest existing packfile is > marked with ".keep" so that it is left untouched while objects in > other packs and loose ones are repacked. > > What's the doneness of this thing? The interdiff since the earlier > one looked reasonable, but I didn't see this round otherwise > scrutinized by reviewers. As noted in 878t9pfu4f@evledraar.gmail.com I've been running both of these in production without issues, and in combination they really improve performance on big repositories (especially nd/repack-keep-pack). I've given them a really close look and am happy to see them merged down, although some bits of nd/pack-objects-pack-struct are way over my head, but Peff has looked at them more closely, and seemed happy-ish with it once the arbitrary limits present in previous rounds went away. > * pw/add-p-select (2018-03-16) 3 commits > - add -p: optimize line selection for short hunks > - add -p: allow line selection to be inverted > - add -p: select individual hunk lines > > "git add -p" interactive interface learned to let users choose > individual added/removed lines to be used in the operation, instead > of accepting or rejecting a whole hunk. > > Expecting a reroll to reignite the discussion. > cf. <9895c7b7-eac4-28c1-90c6-443acd113...@talktalk.net> > > > * ds/commit-graph (2018-04-11) 16 commits
What's cooking in git.git (Apr 2018, #03; Wed, 25)
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. 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"] * ak/bisect-doc-typofix (2018-04-07) 1 commit (merged to 'next' on 2018-04-17 at eafdeb0248) + Documentation/git-bisect.txt: git bisect term → git bisect terms Docfix. * bb/git-gui-ssh-key-files (2018-03-02) 2 commits (merged to 'next' on 2018-04-17 at e439f0398d) + Merge branch 'bb/ssh-key-files' of git-gui into bb/git-gui-ssh-key-files + git-gui: search for all current SSH key types "git gui" learned that "~/.ssh/id_ecdsa.pub" and "~/.ssh/id_ed25519.pub" are also possible SSH key files. * bp/fsmonitor-bufsize-fix (2018-04-11) 1 commit (merged to 'next' on 2018-04-17 at 70a7091e06) + fsmonitor: fix incorrect buffer size when printing version number Fix an unexploitable (because the oversized contents are not under attacker's control) buffer overflow. * bp/fsmonitor-prime-index (2018-04-11) 1 commit (merged to 'next' on 2018-04-17 at 765edccdf0) + fsmonitor: force index write after full scan The index file is updated to record the fsmonitor section after a full scan was made, to avoid wasting the effort that has already spent. * bp/git-gui-bind-kp-enter (2018-03-02) 2 commits (merged to 'next' on 2018-04-17 at 35828e90e2) + Merge branch 'bp/bind-kp-enter' of git-gui into bp/git-gui-bind-kp-enter + git-gui: bind CTRL/CMD+numpad ENTER to do_commit "git gui" performs commit upon CTRL/CMD+ENTER but the CTRL/CMD+KP_ENTER (i.e. enter key on the numpad) did not have the same key binding. It now does. * br/mergetools-guiffy (2018-04-06) 1 commit (merged to 'next' on 2018-04-17 at 8ec0697d5d) + mergetools: add support for guiffy "git mergetools" learned talking to guiffy. * bw/commit-partial-from-subdirectory-fix (2018-04-05) 1 commit (merged to 'next' on 2018-04-17 at 1e56bbc14d) + commit: allow partial commits with relative paths "cd sub/dir && git commit ../path" ought to record the changes to the file "sub/path", but this regressed long time ago. * cb/bash-completion-ls-files-processing (2018-04-10) 1 commit (merged to 'next' on 2018-04-17 at 956b155366) + completion: improve ls-files filter performance Shell completion (in contrib) that gives list of paths have been optimized somewhat. * cb/git-gui-ttk-style (2018-03-05) 2 commits (merged to 'next' on 2018-04-17 at 1a4f677a0d) + Merge branch 'cb/ttk-style' of git-gui into cb/git-gui-ttk-style + git-gui: workaround ttk:style theme use "git gui" has been taught to work with old versions of tk (like 8.5.7) that do not support "ttk::style theme use" as a way to query the current theme. * cc/perf-bisect (2018-04-11) 2 commits (merged to 'next' on 2018-04-17 at 62a1498dd0) + t/perf: add scripts to bisect performance regressions + perf/run: add --subsection option Performance measuring framework in t/perf learned to help bisecting performance regressions. * en/doc-typoes (2018-04-09) 2 commits (merged to 'next' on 2018-04-17 at 81e5c8da18) + Documentation: normalize spelling of 'normalised' + Documentation: fix several one-character-off spelling errors Docfix. * es/fread-reads-dir-autoconf-fix (2018-04-09) 1 commit (merged to 'next' on 2018-04-17 at 538601fef3) + configure.ac: fix botched FREAD_READS_DIRECTORIES check Small fix to the autoconf build procedure. * es/worktree-docs (2018-04-09) 2 commits (merged to 'next' on 2018-04-17 at 15a098e9b1) + git-worktree.txt: unify command-line prompt in example blocks + git-worktree.txt: recommend 'git worktree remove' over manual deletion (this branch uses nd/worktree-move.) Doc updates. * jk/flockfile-stdio (2018-03-30) 1 commit (merged to 'next' on 2018-04-17 at e11bd565f4) + config: move flockfile() closer to unlocked functions Code clean-up. * jk/ref-array-push (2018-04-09) 3 commits (merged to 'next' on 2018-04-17 at 61859b271b) + ref-filter: factor ref_array pushing into its own function + ref-filter: make ref_array_item allocation more consistent + ref-filter: use "struct object_id" consistently (this branch is used by hn/sort-ls-remote.) API clean-up aournd ref-filter code. * jk/relative-directory-fix (2018-03-30) 5 commits (merged to 'next' on 2018-04-17 at 1b8cc9dcb4) + refs: use chdir_notify to update cached relative paths + set_work_tree: use chdir_notify + add chdir-notify API + trace.c: export trace_setup_key + set_git_dir: die when setenv() fails Some codepaths, including the refs API, get and keep relative paths, that go out of sync when the process does chdir(2). The