What's cooking in git.git (Oct 2018, #01; Wed, 10)

What's cooking in git.git (Oct 2018, #01; Wed, 10)

[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.

We haven't seen much complaints and breakages reported against the
two big "rewrite in C" topics around "rebase"; perhaps it is a good
time to merge them to 'next' soonish to cook them for a few weeks
before moving them to 'master'?

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"]

* ab/fsck-skiplist (2018-09-12) 10 commits
  (merged to 'next' on 2018-09-24 at 26adeb8b8f)
 + fsck: support comments & empty lines in skipList
 + fsck: use oidset instead of oid_array for skipList
 + fsck: use strbuf_getline() to read skiplist file
 + fsck: add a performance test for skipList
 + fsck: add a performance test
 + fsck: document that skipList input must be unabbreviated
 + fsck: document and test commented & empty line skipList input
 + fsck: document and test sorted skipList input
 + fsck tests: add a test for no skipList input
 + fsck tests: setup of bogus commit object

 (Originally merged to 'next' on 2018-09-17 at dc9094ba9b)

 Update fsck.skipList implementation and documentation.


* bc/hash-independent-tests (2018-09-17) 11 commits
  (merged to 'next' on 2018-09-24 at 7c4a61fe46)
 + t5318: use test_oid for HASH_LEN
 + t1407: make hash size independent
 + t1406: make hash-size independent
 + t1405: make hash size independent
 + t1400: switch hard-coded object ID to variable
 + t1006: make hash size independent
 + t0064: make hash size independent
 + t0002: abstract away SHA-1 specific constants
 + t0000: update tests for SHA-256
 + t0000: use hash translation table
 + t: add test functions to translate hash-related values

 (Originally merged to 'next' on 2018-09-17 at 9e94794d05)

 Various tests have been updated to make it easier to swap the
 hash function used for object identification.


* ds/multi-pack-verify (2018-09-17) 11 commits
  (merged to 'next' on 2018-09-24 at f294a34aaf)
 + fsck: verify multi-pack-index
 + multi-pack-index: report progress during 'verify'
 + multi-pack-index: verify object offsets
 + multi-pack-index: fix 32-bit vs 64-bit size check
 + multi-pack-index: verify oid lookup order
 + multi-pack-index: verify oid fanout order
 + multi-pack-index: verify missing pack
 + multi-pack-index: verify packname order
 + multi-pack-index: verify corrupt chunk lookup table
 + multi-pack-index: verify bad header
 + multi-pack-index: add 'verify' verb

 (Originally merged to 'next' on 2018-09-17 at f27244f302)

 "git multi-pack-index" learned to detect corruption in the .midx
 file it uses, and this feature has been integrated into "git fsck".


* nd/config-split (2018-09-12) 11 commits
  (merged to 'next' on 2018-09-24 at 150cb40d2c)
 + config.txt: move submodule part out to a separate file
 + config.txt: move sequence.editor out of "core" part
 + config.txt: move sendemail part out to a separate file
 + config.txt: move receive part out to a separate file
 + config.txt: move push part out to a separate file
 + config.txt: move pull part out to a separate file
 + config.txt: move gui part out to a separate file
 + config.txt: move gitcvs part out to a separate file
 + config.txt: move format part out to a separate file
 + config.txt: move fetch part out to a separate file
 + config.txt: follow camelCase naming

 (Originally merged to 'next' on 2018-09-17 at 33e6cb8f48)

 Split Documentation/config.txt for easier maintenance.


* nd/test-tool (2018-09-11) 6 commits
  (merged to 'next' on 2018-09-24 at 23ad767573)
 + Makefile: add a hint about TEST_BUILTINS_OBJS
 + t/helper: merge test-dump-fsmonitor into test-tool
 + t/helper: merge test-parse-options into test-tool
 + t/helper: merge test-pkt-line into test-tool
 + t/helper: merge test-dump-untracked-cache into test-tool
 + t/helper: keep test-tool command list sorted

 (Originally merged to 'next' on 2018-09-17 at decbf86eeb)

 Test helper binaries clean-up.

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

* ds/reachable-final-cleanup (2018-09-25) 1 commit
 - commit-reach: cleanups in can_all_from_reach...

 Code already in 'master' is further cleaned-up by this patch.

 Will merge to 'next'.


* dz/credential-doc-url-matching-rules (2018-09-27) 1 commit
 - doc: clarify gitcredentials path component matching

 Doc update.

 Will merge to 'next'.


* en/status-multiple-renames-to-the-same-target-fix (2018-09-27) 1 commit
 - commit: fix erroneous BUG, 'multiple renames on the same target? how?'

 The code in "git status" sometimes hit an assertion failure.  This
 was caused by a structure that was reused without cleaning the data
 used for the first run, which has been corrected.

 Will merge to 'next'.


* jc/how-to-document-api (2018-09-29) 1 commit
 - CodingGuidelines: document the API in *.h files

 Doc update.

 Will merge to 'next'.


* jc/rebase-in-c-5-test-typofix (2018-09-28) 1 commit
 - rebase: fix typoes in error messages
 (this branch uses pk/rebase-in-c, pk/rebase-in-c-2-basic, pk/rebase-in-c-3-acts, pk/rebase-in-c-4-opts and pk/rebase-in-c-5-test; is tangled with js/rebase-in-c-5.5-work-with-rebase-i-in-c and pk/rebase-in-c-6-final.)

 Typofix.


* jc/war-on-string-list (2018-09-28) 1 commit
 - fetch: replace string-list used as a look-up table with a hashmap

 Replace two string-list instances used as look-up tables in "git
 fetch" with a pair of hashmaps.  WIP as there is another such use
 of string-list nearby that should be converted at the same time.


* jk/check-everything-connected-is-long-gone (2018-09-25) 1 commit
 - receive-pack: update comment with check_everything_connected

 Comment fix.

 Will merge to 'next'.


* jk/oideq-hasheq-cleanup (2018-10-04) 1 commit
 - more oideq/hasheq conversions

 Code clean-up.

 Will merge to 'next'.


* js/mingw-wants-vista-or-above (2018-10-04) 3 commits
 - mingw: bump the minimum Windows version to Vista
 - mingw: set _WIN32_WINNT explicitly for Git for Windows
 - compat/poll: prepare for targeting Windows Vista

 The minimum version of Windows supported by Windows port fo Git is
 now set to Vista.

 Will merge to 'next'.


* js/rebase-i-break (2018-10-09) 1 commit
 - rebase -i: introduce the 'break' command
 (this branch uses ag/rebase-i-in-c; is tangled with ag/sequencer-reduce-rewriting-todo, js/rebase-in-c-5.5-work-with-rebase-i-in-c and pk/rebase-in-c-6-final.)

 "git rebase -i" learned a new insn, 'break', that the user can
 insert in the to-do list.  Upon hitting it, the command returns
 control back to the user.

 Will hold, waiting for the "rebase-in-c" and "rebase-i-in-c" topics.


* js/remote-archive-v2 (2018-09-28) 4 commits
 - archive: allow archive over HTTP(S) with proto v2
 - archive: implement protocol v2 archive command
 - archive: use packet_reader for communications
 - archive: follow test standards around assertions

 The original implementation of "git archive --remote" more or less
 bypassed the transport layer and did not work over http(s).  The
 version 2 of the protocol is defined to allow going over http(s) as
 well as Git native transport.

 Will merge to 'next'.


* jt/non-blob-lazy-fetch (2018-10-04) 2 commits
 - fetch-pack: exclude blobs when lazy-fetching trees
 - fetch-pack: avoid object flags if no_dependents

 A partial clone that is configured to lazily fetch missing objects
 will on-demand issue a "git fetch" request to the originating
 repository to fill not-yet-obtained objects.  The request has been
 optimized for requesting a tree object (and not the leaf blob
 objects contained in it) by telling the originating repository that
 no blobs are needed.

 Will merge to 'next'.


* ma/commit-graph-docs (2018-09-27) 4 commits
 - Doc: refer to the "commit-graph file" with dash
 - git-commit-graph.txt: refer to "*commit*-graph file"
 - git-commit-graph.txt: typeset more in monospace
 - git-commit-graph.txt: fix bullet lists

 Doc update.

 Will merge to 'next'.


* ma/mailing-list-address-in-git-help (2018-09-29) 1 commit
 - git doc: direct bug reporters to mailing list archive

 Doc update.

 Will merge to 'next'.


* ma/t1400-undebug-test (2018-09-28) 1 commit
 - t1400: drop debug `echo` to actually execute `test`

 Test fix.

 Will merge to 'next'.


* ma/t7005-bash-workaround (2018-09-28) 1 commit
 - t7005-editor: quote filename to fix whitespace-issue

 Test fix.

 Will merge to 'next'.


* nd/help-commands-verbose-by-default (2018-10-03) 1 commit
 - help -a: improve and make --verbose default

 "git help -a" and "git help -av" give different pieces of
 information, and generally the "verbose" version is more friendly
 to the new users.  "git help -a" by default now uses the more
 verbose output (with "--no-verbose", you can go back to the
 original).  Also "git help -av" now lists aliases and external
 commands, which it did not used to.

 Will merge to 'next'.


* nd/packobjectshook-doc-fix (2018-09-29) 1 commit
 - config.txt: correct the note about uploadpack.packObjectsHook

 Doc update.

 Will merge to 'next'.


* pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
 - diff --color-moved: fix a memory leak
 - diff --color-moved-ws: fix another memory leak
 - diff --color-moved-ws: fix a memory leak
 - diff --color-moved-ws: fix out of bounds string access
 - diff --color-moved-ws: fix double free crash

 Various fixes to "diff --color-moved-ws".

 What's the status of this topic?


* rs/grep-no-recursive (2018-10-03) 1 commit
 - grep: add -r/--[no-]recursive

 Unlike "grep", "git grep" by default recurses to the whole tree.
 The command learned "git grep --recursive" option, so that "git
 grep --no-recursive" can serve as a synonym to setting the
 max-depth to 0.

 Will merge to 'next'.


* rs/oidset-on-khash (2018-10-04) 5 commits
 - oidset: uninline oidset_init()
 - oidset: use khash
 - khash: factor out kh_release_*
 - fetch-pack: load tip_oids eagerly iff needed
 - fetch-pack: factor out is_unmatched_ref()

 The oidset API was built on top of the oidmap API which in turn is
 on the hashmap API.  Replace the implementation to build on top of
 the khash API and gain performance.

 Will merge to 'next'.


* rs/sequencer-oidset-insert-avoids-dups (2018-10-03) 1 commit
 - sequencer: use return value of oidset_insert()

 Code clean-up.

 Will merge to 'next'.


* rt/rebase-typofix (2018-09-28) 1 commit
 - git-rebase.sh: fix typos in error messages

 Typofix.

 Will merge to 'next'.


* rv/alias-help (2018-10-03) 3 commits
 - git-help.txt: document "git help cmd" vs "git cmd --help" for aliases
 - git.c: handle_alias: prepend alias info when first argument is -h
 - help: redirect to aliased commands for "git cmd --help"


* sb/strbuf-h-update (2018-09-29) 1 commit
 - strbuf.h: format according to coding guidelines

 Code clean-up to serve as a BCP example.

 What's the status of this one after the discussion thread stopped here?
 cf. <CAGZ79kbV6QjsFKcD2uG_P9j1AvzSNQSi-_jXGQ9w0YU9fjhEGg@mail.gmail.com>


* sg/split-index-racefix (2018-09-28) 6 commits
 - split-index: smudge and add racily clean cache entries to split index
 - split-index: don't compare stat data of entries already marked for split index
 - split-index: count the number of deleted entries
 - t1700-split-index: date back files to avoid racy situations
 - split-index: add tests to demonstrate the racy split index problem
 - t1700-split-index: document why FSMONITOR is disabled in this test script

 The codepath to support the experimental split-index mode had
 remaining "racily clean" issues fixed.

 Expecting the final one.
 cf. <20181008154126.GY23446@localhost>


* sm/show-superproject-while-conflicted (2018-09-28) 1 commit
 - rev-parse: --show-superproject-working-tree should work during a merge

 A corner-case bugfix.

 Will merge to 'next'.


* ag/sequencer-reduce-rewriting-todo (2018-10-09) 16 commits
 - rebase--interactive: move transform_todo_file() to rebase--interactive.c
 - sequencer: fix a call to error() in transform_todo_file()
 - sequencer: use edit_todo_list() in complete_action()
 - rebase-interactive: rewrite edit_todo_list() to handle the initial edit
 - rebase-interactive: append_todo_help() changes
 - rebase-interactive: use todo_list_transform() in edit_todo_list()
 - sequencer: refactor skip_unnecessary_picks() to work on a todo_list
 - sequencer: change complete_action() to use the refactored functions
 - sequencer: make sequencer_make_script() write its script to a strbuf
 - sequencer: refactor transform_todos() to work on a todo_list
 - sequencer: refactor rearrange_squash() to work on a todo_list
 - sequencer: refactor sequencer_add_exec_commands() to work on a todo_list
 - sequencer: refactor check_todo_list() to work on a todo_list
 - sequencer: make the todo_list structure public
 - sequencer: clear the number of items of a todo_list before parsing
 - Merge branch 'ag/rebase-i-in-c' into ag/sequencer-reduce-rewriting-todo
 (this branch uses ag/rebase-i-in-c; is tangled with js/rebase-i-break, js/rebase-in-c-5.5-work-with-rebase-i-in-c and pk/rebase-in-c-6-final.)

 The scripted version of "git rebase -i" wrote and rewrote the todo
 list many times during a single step of its operation, and the
 recent C-rewrite made a faithful conversion of the logic to C.  The
 implementation has been updated to carry necessary information
 around in-core to avoid rewriting the same file over and over
 unnecessarily.

 Will hold, waiting for the "rebase-in-c" and "rebase-i-in-c" topics.


* bc/editorconfig (2018-10-09) 2 commits
 - editorconfig: indicate settings should be kept in sync
 - editorconfig: provide editor settings for Git developers

 To help developers, an EditorConfig file that attempts to follow
 the project convention has been added.

 Will merge to 'next'.


* bc/hash-transition-part-15 (2018-10-09) 14 commits
 - rerere: convert to use the_hash_algo
 - submodule: make zero-oid comparison hash function agnostic
 - apply: rename new_sha1_prefix and old_sha1_prefix
 - apply: replace hard-coded constants
 - tag: express constant in terms of the_hash_algo
 - transport: use parse_oid_hex instead of a constant
 - upload-pack: express constants in terms of the_hash_algo
 - refs/packed-backend: express constants using the_hash_algo
 - packfile: express constants in terms of the_hash_algo
 - pack-revindex: express constants in terms of the_hash_algo
 - builtin/fetch-pack: remove constants with parse_oid_hex
 - builtin/mktree: remove hard-coded constant
 - builtin/repack: replace hard-coded constant
 - pack-bitmap-write: use GIT_MAX_RAWSZ for allocation


* ch/subtree-build (2018-10-10) 1 commit
 - subtree: add build targets 'man' and 'html'

 Build update for "git subtree" (in contrib/) documentation pages.

 Will merge to 'next'.


* ds/commit-graph-leakfix (2018-10-07) 3 commits
 - commit-graph: reduce initial oid allocation
 - builtin/commit-graph.c: UNLEAK variables
 - commit-graph: clean up leaked memory during write
 (this branch uses ab/commit-graph-progress.)

 Code clean-up.

 Will merge to 'next'.


* ds/test-multi-pack-index (2018-10-09) 3 commits
 - multi-pack-index: define GIT_TEST_MULTI_PACK_INDEX
 - midx: close multi-pack-index on repack
 - midx: fix broken free() in close_midx()

 Tests for the recently introduced multi-pack index machinery.

 Expecting a reroll.
 cf. <8b5dbe3d-b382-bf48-b524-d9e8a074ac4d@gmail.com>


* js/fuzzer (2018-10-10) 2 commits
 - fuzz: add fuzz testing for packfile indices
 - fuzz: add basic fuzz testing target

 An experiment to fuzz test a few areas, hopefully we can gain more
 coverage to various areas.


* jt/avoid-ls-refs (2018-10-07) 4 commits
 - fetch: do not list refs if fetching only hashes
 - transport: list refs before fetch if necessary
 - transport: do not list refs if possible
 - transport: allow skipping of ref listing

 Over some transports, fetching objects with an exact commit object
 name can be done without first seeing the ref advertisements.  The
 code has been optimized to exploit this.

 Will merge to 'next'.


* jt/cache-tree-allow-missing-object-in-partial-clone (2018-10-10) 1 commit
 - cache-tree: skip some blob checks in partial clone

 In a partial clone that will lazily be hydrated from the
 originating repository, we generally want to avoid "does this
 object exist (locally)?" on objects that we deliberately omitted
 when we created the clone.  The cache-tree codepath (which is used
 to write a tree object out of the index) however insisted that the
 object exists, even for paths that are outside of the partial
 checkout area.  The code has been updated to avoid such a check.

 Will merge to 'next'.


* mw/doc-typofixes (2018-10-07) 3 commits
 - docs: typo: s/isimilar/similar/
 - docs: graph: remove unnecessary `graph_update()' call
 - docs: typo: s/go/to/

 Typofixes.

 Will merge to 'next'.


* nd/per-worktree-ref-iteration (2018-10-07) 9 commits
 - SQUASH???
 - reflog expire: cover reflog from all worktrees
 - fsck: check HEAD and reflog from other worktrees
 - fsck: Move fsck_head_link() to get_default_heads() to avoid some globals
 - revision.c: better error reporting on ref from different worktrees
 - revision.c: correct a parameter name
 - refs: new ref types to make per-worktree refs visible to all worktrees
 - Add a place for (not) sharing stuff between worktrees
 - refs.c: indent with tabs, not spaces

 What's the status of this topic?


* np/log-graph-octopus-fix (2018-10-10) 1 commit
 - log: fix coloring of certain octopus merge shapes

 "git log --graph" showing an octopus merge sometimes miscounted the
 number of display columns it is consuming to show the merge and its
 parent commits, which has been corrected.

 Expecting a clarification.
 cf. <xmqqzhvmmv8v.fsf@gitster-ct.c.googlers.com>


* rs/subtree-fixes (2018-10-07) 4 commits
 - subtree: improve decision on merges kept in split
 - subtree: use commits before rejoins for splits
 - subtree: make --ignore-joins pay attention to adds
 - subtree: refactor split of a commit into standalone method

 Various subtree fixes.

 Will merge to 'next'.
 Unless somebody objects, that is.


* sb/grep-submodule-cleanup (2018-10-10) 1 commit
 - builtin/grep.c: remove superfluous submodule code

 Code clean-up.

 cf. <20181010001037.74709-1-jonathantanmy@google.com>


* sf/complete-stash-list (2018-10-07) 1 commit
 - git-completion.bash: add completion for stash list

 The completion script (in contrib/) lerned to complete a handful of
 options "git stash list" command takes.

 Will merge to 'next'.


* tb/filter-alternate-refs (2018-10-09) 4 commits
 - transport.c: introduce core.alternateRefsPrefixes
 - transport.c: introduce core.alternateRefsCommand
 - transport.c: extract 'fill_alternate_refs_command'
 - transport: drop refnames from for_each_alternate_ref

 When pushing into a repository that borrows its objects from an
 alternate object store, "git receive-pack" that responds to the
 push request on the other side lists the tips of refs in the
 alternate to reduce the amount of objects transferred.  This
 sometimes is detrimental when the number of refs in the alternate
 is absurdly large, in which case the bandwidth saved in potentially
 fewer objects transferred is wasted in excessively large ref
 advertisement.  The alternate refs that are advertised are now
 configurable with a pair of configuration variables.

 Will merge to 'next'.

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

* bw/submodule-name-to-dir (2018-08-10) 2 commits
 - submodule: munge paths to submodule git directories
 - submodule: create helper to build paths to submodule gitdirs

 In modern repository layout, the real body of a cloned submodule
 repository is held in .git/modules/ of the superproject, indexed by
 the submodule name.  URLencode the submodule name before computing
 the name of the directory to make sure they form a flat namespace.

 Kicked back to 'pu', expecting further work on the topic.
 cf. <CAGZ79kYnbjaPoWdda0SM_-_X77mVyYC7JO61OV8nm2yj3Q1OvQ@mail.gmail.com>


* ng/status-i-short-for-ignored (2018-08-09) 1 commit
 - status: -i shorthand for --ignored command line option

 "git status --ignored" gained a shorthand "git status -i".

 Will discard, after hearing no strong support.
 What's the list opinion on this one?  It is Meh to me, but
 obviously the author cared enough to write a patch, so...


* sb/submodule-move-head-with-corruption (2018-08-28) 2 commits
 - submodule.c: warn about missing submodule git directories
 - t2013: add test for missing but active submodule

 Will discard and wait for a cleaned-up rewrite.
 cf. <20180907195349.GA103699@aiede.svl.corp.google.com>


* sl/commit-dry-run-with-short-output-fix (2018-07-30) 4 commits
 . commit: fix exit code when doing a dry run
 . wt-status: teach wt_status_collect about merges in progress
 . wt-status: rename commitable to committable
 . t7501: add coverage for flags which imply dry runs

 "git commit --dry-run" gave a correct exit status even during a
 conflict resolution toward a merge, but it did not with the
 "--short" option, which has been corrected.

 Seems to break 7512, 3404 and 7060 in 'pu'.


* ma/wrapped-info (2018-05-28) 2 commits
 - usage: prefix all lines in `vreportf()`, not just the first
 - usage: extract `prefix_suffix_lines()` from `advise()`

 An attempt to help making multi-line messages fed to warning(),
 error(), and friends more easily translatable.

 Will discard and wait for a cleaned-up rewrite.
 cf. <20180529213957.GF7964@sigill.intra.peff.net>


* hn/bisect-first-parent (2018-04-21) 1 commit
 - bisect: create 'bisect_flags' parameter in find_bisection()
 (this branch is used by tb/bisect-first-parent.)

 Preliminary code update to allow passing more flags down the
 bisection codepath in the future.

 We do not add random code that does not have real users to our
 codebase, so let's have it wait until such a real code materializes
 before too long.


* pb/bisect-helper-2 (2018-07-23) 8 commits
 - t6030: make various test to pass GETTEXT_POISON tests
 - bisect--helper: `bisect_start` shell function partially in C
 - bisect--helper: `get_terms` & `bisect_terms` shell function in C
 - bisect--helper: `bisect_next_check` shell function in C
 - bisect--helper: `check_and_set_terms` shell function in C
 - wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
 - bisect--helper: `bisect_write` shell function in C
 - bisect--helper: `bisect_reset` shell function in C

 Expecting a reroll.
 cf. <0102015f5e5ee171-f30f4868-886f-47a1-a4e4-b4936afc545d-000000@eu-west-1.amazonses.com>

 I just rebased the topic to a newer base as it did not build
 standalone with the base I originally queued the topic on, but
 otherwise there is no update to address any of the review comments
 in the thread above---we are still waiting for a reroll.


* jk/drop-ancient-curl (2017-08-09) 5 commits
 - http: #error on too-old curl
 - curl: remove ifdef'd code never used with curl >=7.19.4
 - http: drop support for curl < 7.19.4
 - http: drop support for curl < 7.16.0
 - http: drop support for curl < 7.11.1

 Some code in http.c that has bitrot is being removed.

 Expecting a reroll.


* mk/use-size-t-in-zlib (2017-08-10) 1 commit
 . zlib.c: use size_t for size

 The wrapper to call into zlib followed our long tradition to use
 "unsigned long" for sizes of regions in memory, which have been
 updated to use "size_t".

 Needs resurrecting by making sure the fix is good and still applies
 (or adjusted to today's codebase).

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

* fe/doc-updates (2018-09-21) 3 commits
  (merged to 'next' on 2018-10-10 at 2eea3a88bc)
 + git-describe.1: clarify that "human readable" is also git-readable
 + git-column.1: clarify initial description, provide examples
 + git-archimport.1: specify what kind of Arch we're talking about

 Doc updates.

 Will merge to 'master'.


* md/test-cleanup (2018-10-07) 7 commits
  (merged to 'next' on 2018-10-10 at 7e0bf1b573)
 + tests: order arguments to git-rev-list properly
 + t9109: don't swallow Git errors upstream of pipes
 + tests: don't swallow Git errors upstream of pipes
 + t/*: fix ordering of expected/observed arguments
 + tests: standardize pipe placement
 + Documentation: add shell guidelines
 + t/README: reformat Do, Don't, Keep in mind lists

 Various test scripts have been updated for style and also correct
 handling of exit status of various commands.

 Will merge to 'master'.


* nd/complete-fetch-multiple-args (2018-09-21) 1 commit
  (merged to 'next' on 2018-10-10 at f78e14123c)
 + completion: support "git fetch --multiple"

 Teach bash completion that "git fetch --multiple" only takes remote
 names as arguments and no refspecs.

 Will merge to 'master'.


* jt/fetch-tips-in-partial-clone (2018-09-21) 2 commits
 - fetch: in partial clone, check presence of targets
 - connected: document connectivity in partial clones

 "git fetch $repo $object" in a partial clone did not correctly
 fetch the asked-for object that is referenced by an object in
 promisor packfile, which has been fixed.

 Will merge to 'next'.


* tg/t5551-with-curl-7.61.1 (2018-09-24) 2 commits
  (merged to 'next' on 2018-10-10 at 5ada84ed7a)
 + t5551: compare sorted cookies files
 + t5551: move setup code inside test_expect blocks

 Test update.

 Will merge to 'master'.
 Supersedes tz/t5551-with-curl-7.61.1 topic


* jn/gc-auto-prep (2018-07-17) 2 commits
  (merged to 'next' on 2018-10-10 at 4ab6a62f62)
 + gc: exit with status 128 on failure
 + gc: improve handling of errors reading gc.log
 (this branch is used by jn/gc-auto.)

 Code clean-up.

 Will merge to 'master'.


* nd/status-refresh-progress (2018-09-17) 1 commit
 - status: show progress bar if refreshing the index takes too long

 "git status" learns to show progress bar when refreshing the index
 takes a long time.

 Will merge to 'next'.


* nd/the-index (2018-09-21) 23 commits
  (merged to 'next' on 2018-10-10 at 16e2e2e947)
 + revision.c: reduce implicit dependency the_repository
 + revision.c: remove implicit dependency on the_index
 + ws.c: remove implicit dependency on the_index
 + tree-diff.c: remove implicit dependency on the_index
 + submodule.c: remove implicit dependency on the_index
 + line-range.c: remove implicit dependency on the_index
 + userdiff.c: remove implicit dependency on the_index
 + rerere.c: remove implicit dependency on the_index
 + sha1-file.c: remove implicit dependency on the_index
 + patch-ids.c: remove implicit dependency on the_index
 + merge.c: remove implicit dependency on the_index
 + merge-blobs.c: remove implicit dependency on the_index
 + ll-merge.c: remove implicit dependency on the_index
 + diff-lib.c: remove implicit dependency on the_index
 + read-cache.c: remove implicit dependency on the_index
 + diff.c: remove implicit dependency on the_index
 + grep.c: remove implicit dependency on the_index
 + diff.c: remove the_index dependency in textconv() functions
 + blame.c: rename "repo" argument to "r"
 + combine-diff.c: remove implicit dependency on the_index
 + diff.c: reduce implicit dependency on the_index
 + read-cache.c: remove 'const' from index_has_changes()
 + archive.c: remove implicit dependency the_repository

 Various codepaths in the core-ish part learn to work on an
 arbitrary in-core index structure, not necessarily the default
 instance "the_index".

 Will merge to 'master'.


* tq/refs-internal-comment-fix (2018-09-17) 1 commit
  (merged to 'next' on 2018-10-09 at 422313bbd0)
 + refs: docstring typo

 Fix for typo in a sample code in comment.

 Will merge to 'master'.


* ts/alias-of-alias (2018-09-17) 3 commits
  (merged to 'next' on 2018-10-09 at ac19b4730b)
 + t0014: introduce an alias testing suite
 + alias: show the call history when an alias is looping
 + alias: add support for aliases of an alias

 An alias that expands to another alias has so far been forbidden,
 but now it is allowed to create such an alias.

 Will merge to 'master'.


* ds/reachable-topo-order (2018-09-21) 7 commits
 - revision.c: refactor basic topo-order logic
 - revision.h: add whitespace in flag definitions
 - commit/revisions: bookkeeping before refactoring
 - revision.c: begin refactoring --topo-order logic
 - test-reach: add rev-list tests
 - test-reach: add run_three_modes method
 - prio-queue: add 'peek' operation

 The revision walker machinery learned to take advantage of the
 commit generation numbers stored in the commit-graph file.

 What's the status of this topic?


* en/merge-cleanup (2018-09-20) 4 commits
  (merged to 'next' on 2018-10-09 at f3a00b506f)
 + merge-recursive: rename merge_file_1() and merge_content()
 + merge-recursive: remove final remaining caller of merge_file_one()
 + merge-recursive: avoid wrapper function when unnecessary and wasteful
 + merge-recursive: set paths correctly when three-way merging content

 Code clean-up.

 Will merge to 'master'.


* jk/delta-islands-with-bitmap-reuse-delta-fix (2018-09-19) 1 commit
  (merged to 'next' on 2018-10-09 at 10e58be2af)
 + pack-objects: handle island check for "external" delta base

 Fix interactions between two recent topics.

 Will merge to 'master'.


* jn/mailmap-update (2018-09-25) 1 commit
  (merged to 'next' on 2018-10-10 at fa2b394bd5)
 + mailmap: consistently normalize brian m. carlson's name

 The mailmap file update.

 Will merge to 'master'.


* ma/config-doc-update (2018-09-20) 2 commits
  (merged to 'next' on 2018-10-09 at 312a873a2a)
 + git-config.txt: fix 'see: above' note
 + Doc: use `--type=bool` instead of `--bool`

 Doc update.

 Will merge to 'master'.


* rj/header-check (2018-09-20) 8 commits
  (merged to 'next' on 2018-10-09 at 7fa9c68ef0)
 + delta-islands.h: add missing forward declarations (hdr-check)
 + midx.h: add missing forward declarations (hdr-check)
 + refs/refs-internal.h: add missing declarations (hdr-check)
 + refs/packed-backend.h: add missing declaration (hdr-check)
 + refs/ref-cache.h: add missing declarations (hdr-check)
 + ewah/ewok_rlw.h: add missing include (hdr-check)
 + json-writer.h: add missing include (hdr-check)
 + Makefile: add a hdr-check target

 Header files clean-up.

 Will merge to 'master'.


* bp/read-cache-parallel (2018-09-28) 8 commits
 - read-cache: fix division by zero core-dump
 - read-cache: load cache entries on worker threads
 - ieot: add Index Entry Offset Table (IEOT) extension
 - read-cache: load cache extensions on a worker thread
 - config: add new index.threads config setting
 - eoie: add End of Index Entry (EOIE) extension
 - read-cache: clean up casting and byte decoding
 - read-cache.c: optimize reading index format v4

 A new extension to the index file has been introduced, which allows
 the file to be read in parallel.

 Will merge to 'next'.


* ds/coverage-diff (2018-10-10) 1 commit
 - contrib: add coverage-diff script

 The result of coverage test can be combined with "git blame" to
 check the test coverage of code introduced recently with a new
 'coverage-diff' tool (in contrib/).


* sb/submodule-recursive-fetch-gets-the-tip (2018-09-12) 9 commits
 - builtin/fetch: check for submodule updates for non branch fetches
 - fetch: retry fetching submodules if sha1 were not fetched
 - submodule: fetch in submodules git directory instead of in worktree
 - submodule.c: do not copy around submodule list
 - submodule: move global changed_submodule_names into fetch submodule struct
 - submodule.c: sort changed_submodule_names before searching it
 - submodule.c: fix indentation
 - sha1-array: provide oid_array_filter
 - string-list: add string_list_{pop, last} functions

 "git fetch --recurse-submodules" may not fetch the necessary commit
 that is bound to the superproject, which is getting corrected.

 Expecting a reroll.
 cf. <CAGZ79kbavjVbTqXsmtjW6=jhkq47_p3mc6=92xOp4_mfhqDtvw@mail.gmail.com>
 cf. <b16af8c0-0435-0de4-ed6c-53888d6190af@ramsayjones.plus.com>
 cf. <CAGZ79kZKKf9N8yx9EuCRZhrZS_mA2218PouEG7aHDhK2bJGEdA@mail.gmail.com>


* bp/rename-test-env-var (2018-09-28) 6 commits
 - t0000: do not get self-test disrupted by environment warnings
 - preload-index: update GIT_FORCE_PRELOAD_TEST support
 - read-cache: update TEST_GIT_INDEX_VERSION support
 - fsmonitor: update GIT_TEST_FSMONITOR support
 - preload-index: use git_env_bool() not getenv() for customization
 - t/README: correct spelling of "uncommon"

 Some environment variables that control the runtime options of Git
 used during tests are getting renamed for consistency.

 Will merge to 'next'.


* ab/commit-graph-progress (2018-09-20) 3 commits
  (merged to 'next' on 2018-09-24 at 76f2f5c1e3)
 + gc: fix regression in 7b0f229222 impacting --quiet
 + commit-graph verify: add progress output
 + commit-graph write: add progress output
 (this branch is used by ds/commit-graph-leakfix.)

 (Originally merged to 'next' on 2018-09-20 at 24ca94b1d4)

 Generation of (expermental) commit-graph files have so far been
 fairly silent, even though it takes noticeable amount of time in a
 meaningfully large repository.  The users will now see progress
 output.

 Will merge to 'master'.


* ss/wt-status-committable (2018-10-03) 5 commits
  (merged to 'next' on 2018-10-10 at ea30d8819d)
 + roll wt_status_state into wt_status and populate in the collect phase
 + wt-status.c: set the committable flag in the collect phase
 + t7501: add test of "commit --dry-run --short"
 + wt-status: rename commitable to committable
 + wt-status.c: move has_unmerged earlier in the file
 (this branch is tangled with jc/wt-status-state-cleanup.)

 Code clean-up in the internal machinery used by "git status" and
 "git commit --dry-run".

 Will merge to 'master'.


* ds/format-commit-graph-docs (2018-08-21) 2 commits
 - commit-graph.txt: improve formatting for asciidoc
 - Docs: Add commit-graph tech docs to Makefile

 Design docs for the commit-graph machinery is now made into HTML as
 well as text.

 Will discard.
 I am inclined to drop these, as I do not see much clarity in HTML
 output over the text source.  Opinions?


* js/rebase-in-c-5.5-work-with-rebase-i-in-c (2018-10-09) 2 commits
 - builtin rebase: prepare for builtin rebase -i
 - Merge branch 'ag/rebase-i-in-c' into js/rebase-in-c-5.5-work-with-rebase-i-in-c
 (this branch is used by pk/rebase-in-c-6-final; uses ag/rebase-i-in-c, pk/rebase-in-c, pk/rebase-in-c-2-basic, pk/rebase-in-c-3-acts, pk/rebase-in-c-4-opts and pk/rebase-in-c-5-test; is tangled with ag/sequencer-reduce-rewriting-todo, jc/rebase-in-c-5-test-typofix and js/rebase-i-break.)

 "rebase" that has been rewritten learns the new calling convention
 used by "rebase -i" that was rewritten in C, tying the loose end
 between two GSoC topics that stomped on each other's toes.


* js/add-i-coalesce-after-editing-hunk (2018-08-28) 1 commit
 - add -p: coalesce hunks before testing applicability

 Applicability check after a patch is edited in a "git add -i/p"
 session has been improved.

 Will hold.
 cf. <e5b2900a-0558-d3bf-8ea1-d526b078bbc2@talktalk.net>


* ao/submodule-wo-gitmodules-checked-out (2018-10-09) 10 commits
 - t/helper: add test-submodule-nested-repo-config
 - submodule: support reading .gitmodules when it's not in the working tree
 - submodule: add a helper to check if it is safe to write to .gitmodules
 - t7506: clean up .gitmodules properly before setting up new scenario
 - submodule: use the 'submodule--helper config' command
 - submodule--helper: add a new 'config' subcommand
 - t7411: be nicer to future tests and really clean things up
 - t7411: merge tests 5 and 6
 - submodule: factor out a config_set_in_gitmodules_file_gently function
 - submodule: add a print_config_from_gitmodules() helper

 The submodule support has been updated to read from the blob at
 HEAD:.gitmodules when the .gitmodules file is missing from the
 working tree.


* md/filter-trees (2018-10-07) 8 commits
 - list-objects-filter: implement filter tree:0
 - list-objects-filter-options: do not over-strbuf_init
 - list-objects-filter: use BUG rather than die
 - revision: mark non-user-given objects instead
 - rev-list: handle missing tree objects properly
 - list-objects: always parse trees gently
 - list-objects: refactor to process_tree_contents
 - list-objects: store common func args in struct

 The "rev-list --filter" feature learned to exclude all trees via
 "tree:0" filter.

 Will merge to 'next'.


* pk/rebase-in-c-2-basic (2018-09-06) 11 commits
 - builtin rebase: support `git rebase <upstream> <switch-to>`
 - builtin rebase: only store fully-qualified refs in `options.head_name`
 - builtin rebase: start a new rebase only if none is in progress
 - builtin rebase: support --force-rebase
 - builtin rebase: try to fast forward when possible
 - builtin rebase: require a clean worktree
 - builtin rebase: support the `verbose` and `diffstat` options
 - builtin rebase: support --quiet
 - builtin rebase: handle the pre-rebase hook and --no-verify
 - builtin rebase: support `git rebase --onto A...B`
 - builtin rebase: support --onto
 (this branch is used by jc/rebase-in-c-5-test-typofix, js/rebase-in-c-5.5-work-with-rebase-i-in-c, pk/rebase-in-c-3-acts, pk/rebase-in-c-4-opts, pk/rebase-in-c-5-test and pk/rebase-in-c-6-final; uses pk/rebase-in-c.)


* pk/rebase-in-c-3-acts (2018-09-06) 7 commits
 - builtin rebase: stop if `git am` is in progress
 - builtin rebase: actions require a rebase in progress
 - builtin rebase: support --edit-todo and --show-current-patch
 - builtin rebase: support --quit
 - builtin rebase: support --abort
 - builtin rebase: support --skip
 - builtin rebase: support --continue
 (this branch is used by jc/rebase-in-c-5-test-typofix, js/rebase-in-c-5.5-work-with-rebase-i-in-c, pk/rebase-in-c-4-opts, pk/rebase-in-c-5-test and pk/rebase-in-c-6-final; uses pk/rebase-in-c and pk/rebase-in-c-2-basic.)


* pk/rebase-in-c-4-opts (2018-09-06) 18 commits
 - builtin rebase: support --root
 - builtin rebase: add support for custom merge strategies
 - builtin rebase: support `fork-point` option
 - merge-base --fork-point: extract libified function
 - builtin rebase: support --rebase-merges[=[no-]rebase-cousins]
 - builtin rebase: support `--allow-empty-message` option
 - builtin rebase: support `--exec`
 - builtin rebase: support `--autostash` option
 - builtin rebase: support `-C` and `--whitespace=<type>`
 - builtin rebase: support `--gpg-sign` option
 - builtin rebase: support `--autosquash`
 - builtin rebase: support `keep-empty` option
 - builtin rebase: support `ignore-date` option
 - builtin rebase: support `ignore-whitespace` option
 - builtin rebase: support --committer-date-is-author-date
 - builtin rebase: support --rerere-autoupdate
 - builtin rebase: support --signoff
 - builtin rebase: allow selecting the rebase "backend"
 (this branch is used by jc/rebase-in-c-5-test-typofix, js/rebase-in-c-5.5-work-with-rebase-i-in-c, pk/rebase-in-c-5-test and pk/rebase-in-c-6-final; uses pk/rebase-in-c, pk/rebase-in-c-2-basic and pk/rebase-in-c-3-acts.)


* pk/rebase-in-c-5-test (2018-09-06) 6 commits
 - builtin rebase: error out on incompatible option/mode combinations
 - builtin rebase: use no-op editor when interactive is "implied"
 - builtin rebase: show progress when connected to a terminal
 - builtin rebase: fast-forward to onto if it is a proper descendant
 - builtin rebase: optionally pass custom reflogs to reset_head()
 - builtin rebase: optionally auto-detect the upstream
 (this branch is used by jc/rebase-in-c-5-test-typofix, js/rebase-in-c-5.5-work-with-rebase-i-in-c and pk/rebase-in-c-6-final; uses pk/rebase-in-c, pk/rebase-in-c-2-basic, pk/rebase-in-c-3-acts and pk/rebase-in-c-4-opts.)


* pk/rebase-in-c-6-final (2018-10-09) 1 commit
 - rebase: default to using the builtin rebase
 (this branch uses ag/rebase-i-in-c, js/rebase-in-c-5.5-work-with-rebase-i-in-c, pk/rebase-in-c, pk/rebase-in-c-2-basic, pk/rebase-in-c-3-acts, pk/rebase-in-c-4-opts and pk/rebase-in-c-5-test; is tangled with ag/sequencer-reduce-rewriting-todo, jc/rebase-in-c-5-test-typofix and js/rebase-i-break.)

 The final step of rewriting "rebase -i" in C.

 Undecided.
 I've been using this (i.e. the whole "rebase -i" and "rebase"
 rewritten in C) in my personal build, and I also know users on
 Windows port have been using it with the last feature release.  I
 am tempted to merge the whole thing to 'next' soonish.

 Opinions?  It's the last chance to remove any existing and avoid
 any future "oops, that was wrong, and here is a fix-up"
 embarrassment in these topics.


* ps/stash-in-c (2018-08-31) 20 commits
 - stash: replace all `write-tree` child processes with API calls
 - stash: optimize `get_untracked_files()` and `check_changes()`
 - stash: convert `stash--helper.c` into `stash.c`
 - stash: convert save to builtin
 - stash: make push -q quiet
 - stash: convert push to builtin
 - stash: convert create to builtin
 - stash: convert store to builtin
 - stash: mention options in `show` synopsis
 - stash: convert show to builtin
 - stash: convert list to builtin
 - stash: convert pop to builtin
 - stash: convert branch to builtin
 - stash: convert drop and clear to builtin
 - stash: convert apply to builtin
 - stash: add tests for `git stash show` config
 - stash: rename test cases to be more descriptive
 - stash: update test cases conform to coding guidelines
 - stash: improve option parsing test coverage
 - sha1-name.c: add `get_oidf()` which acts like `get_oid()`

 "git stash" rewritten in C.

 Undecided.  This also has been part of my personal build.  I do not
 offhand recall if this also had the same exposure to the end users
 as "rebase" and "rebase -i".  I am tempted to merge this to 'next'
 soonish.

 Opinions?


* pw/add-p-select (2018-07-26) 4 commits
 - add -p: optimize line selection for short hunks
 - add -p: allow line selection to be inverted
 - add -p: select modified lines correctly
 - 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.

 Will discard.
 No further feedbacks on the topic for quite some time.

 cf. <d622a95b-7302-43d4-4ec9-b2cf3388c653@talktalk.net>
 I found the feature to be hard to explain, and may result in more
 end-user complaints, but let's see.


* ds/commit-graph-with-grafts (2018-08-21) 8 commits
  (merged to 'next' on 2018-10-09 at 851a457102)
 + commit-graph: close_commit_graph before shallow walk
 + commit-graph: not compatible with uninitialized repo
 + commit-graph: not compatible with grafts
 + commit-graph: not compatible with replace objects
 + test-repository: properly init repo
 + commit-graph: update design document
 + refs.c: upgrade for_each_replace_ref to be a each_repo_ref_fn callback
 + refs.c: migrate internal ref iteration to pass thru repository argument

 The recently introduced commit-graph auxiliary data is incompatible
 with mechanisms such as replace & grafts that "breaks" immutable
 nature of the object reference relationship.  Disable optimizations
 based on its use (and updating existing commit-graph) when these
 incompatible features are in use in the repository.

 Will merge to 'master'.


* jn/gc-auto (2018-07-17) 1 commit
  (merged to 'next' on 2018-10-10 at 9f0f1f770e)
 + gc: do not return error for prior errors in daemonized mode
 (this branch uses jn/gc-auto-prep.)

 "gc --auto" ended up calling exit(-1) upon error, which has been
 corrected to use exit(1).  Also the error reporting behaviour when
 daemonized has been updated to exit with zero status when stopping
 due to a previously discovered error (which implies there is no
 point running gc to improve the situation); we used to exit with
 failure in such a case.

 Will merge to 'master'.
 cf. <20180917182639.GB140909@aiede.svl.corp.google.com>
 cf. <20181009234502.oxzfwirjcew2sxrm@dcvr>


* ag/rebase-i-in-c (2018-10-09) 20 commits
 - rebase -i: move rebase--helper modes to rebase--interactive
 - rebase -i: remove git-rebase--interactive.sh
 - rebase--interactive2: rewrite the submodes of interactive rebase in C
 - rebase -i: implement the main part of interactive rebase as a builtin
 - rebase -i: rewrite init_basic_state() in C
 - rebase -i: rewrite write_basic_state() in C
 - rebase -i: rewrite the rest of init_revisions_and_shortrevisions() in C
 - rebase -i: implement the logic to initialize $revisions in C
 - rebase -i: remove unused modes and functions
 - rebase -i: rewrite complete_action() in C
 - t3404: todo list with commented-out commands only aborts
 - sequencer: change the way skip_unnecessary_picks() returns its result
 - sequencer: refactor append_todo_help() to write its message to a buffer
 - rebase -i: rewrite checkout_onto() in C
 - rebase -i: rewrite setup_reflog_action() in C
 - sequencer: add a new function to silence a command, except if it fails
 - rebase -i: rewrite the edit-todo functionality in C
 - editor: add a function to launch the sequence editor
 - rebase -i: rewrite append_todo_help() in C
 - sequencer: make three functions and an enum from sequencer.c public
 (this branch is used by ag/sequencer-reduce-rewriting-todo, js/rebase-i-break, js/rebase-in-c-5.5-work-with-rebase-i-in-c and pk/rebase-in-c-6-final.)

 Rewrite of the remaining "rebase -i" machinery in C.


* lt/date-human (2018-07-09) 1 commit
 - Add 'human' date format

 A new date format "--date=human" that morphs its output depending
 on how far the time is from the current time has been introduced.
 "--date=auto" can be used to use this new format when the output is
 goint to the pager or to the terminal and otherwise the default
 format.


* pk/rebase-in-c (2018-08-06) 3 commits
 - builtin/rebase: support running "git rebase <upstream>"
 - rebase: refactor common shell functions into their own file
 - rebase: start implementing it as a builtin
 (this branch is used by jc/rebase-in-c-5-test-typofix, js/rebase-in-c-5.5-work-with-rebase-i-in-c, pk/rebase-in-c-2-basic, pk/rebase-in-c-3-acts, pk/rebase-in-c-4-opts, pk/rebase-in-c-5-test and pk/rebase-in-c-6-final.)

 Rewrite of the "rebase" machinery in C.

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

* tz/t5551-with-curl-7.61.1 (2018-09-17) 1 commit
 . t5551-http-fetch-smart.sh: sort cookies before comparing

 Test fix.

 Discarded to be replaced with tg/t5551-with-curl-7.61.1 topic.


* jc/wt-status-state-cleanup (2018-09-07) 1 commit
 . WIP: roll wt_status_state into wt_status and populate in the collect phase

 A cleaned-up version appears as a part of ss/wt-status-committable.

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Ævar Arnfjörð Bjarmason]

On Wed, Oct 10 2018, Junio C Hamano wrote:

> * jk/drop-ancient-curl (2017-08-09) 5 commits
>  - http: #error on too-old curl
>  - curl: remove ifdef'd code never used with curl >=7.19.4
>  - http: drop support for curl < 7.19.4
>  - http: drop support for curl < 7.16.0
>  - http: drop support for curl < 7.11.1
>
>  Some code in http.c that has bitrot is being removed.
>
>  Expecting a reroll.

There's been no activity on this for 6 months since I sent a "hey what's
going on with it" E-Mail in:
https://public-inbox.org/git/20180404204920.GA15402@sigill.intra.peff.net/

Maybe it should just be dropped?

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Jeff King]

On Wed, Oct 10, 2018 at 09:59:16AM +0200, Ævar Arnfjörð Bjarmason wrote:

> 
> On Wed, Oct 10 2018, Junio C Hamano wrote:
> 
> > * jk/drop-ancient-curl (2017-08-09) 5 commits
> >  - http: #error on too-old curl
> >  - curl: remove ifdef'd code never used with curl >=7.19.4
> >  - http: drop support for curl < 7.19.4
> >  - http: drop support for curl < 7.16.0
> >  - http: drop support for curl < 7.11.1
> >
> >  Some code in http.c that has bitrot is being removed.
> >
> >  Expecting a reroll.
> 
> There's been no activity on this for 6 months since I sent a "hey what's
> going on with it" E-Mail in:
> https://public-inbox.org/git/20180404204920.GA15402@sigill.intra.peff.net/
> 
> Maybe it should just be dropped?

That's fine with me. I think it was a nice cleanup as long as nobody
cared, but some people did seem to care. Maybe they care less now that
more time has passed, but it just hasn't really been worth the time to
revisit.

I'm OK to drop it; the patches are on the list if we want to look at it
again later.

-Peff

builtin stash/rebase, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Johannes Schindelin]

Hi Junio,

On Wed, 10 Oct 2018, Junio C Hamano wrote:

> We haven't seen much complaints and breakages reported against the
> two big "rewrite in C" topics around "rebase"; perhaps it is a good
> time to merge them to 'next' soonish to cook them for a few weeks
> before moving them to 'master'?

I would be in favor, as long as the fixup patches I have in Git for
Windows made it in:

https://github.com/git-for-windows/git/commit/6bc7024aecdb1aeb2760c519f7b26e6e5ef21051
    fixup! builtin rebase: support `-C` and `--whitespace=<type>`

https://github.com/git-for-windows/git/commit/1e6a1c510ffeae5bb0a4bda7f0528a8213728837
    fixup! builtin rebase: support `--gpg-sign` option

https://github.com/git-for-windows/git/commit/ddb6e5ca19d5cdd318bc4bcbb7f7f3fb0892c8cc
    fixup! rebase -i: implement the main part of interactive rebase as a builtin

https://github.com/git-for-windows/git/commit/2af24038a95a3879aa0c29d91a43180b9465247e
    fixup! stash: convert apply to builtin

It seems that Alban picked up the `rebase -i` one, but the other three
have not made it into `pu` yet (the two `rebase` ones are really my fault,
I did not yet find time).

Speaking about the two `rebase` ones: they are simple fixup! commits,
could I trouble you to fetch and cherry-pick them into `pu`, or would you
prefer if I sent another iteration of `rebase-in-c-4-opts`?

Ciao,
Dscho

Re: builtin stash/rebase, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Speaking about the two `rebase` ones: they are simple fixup! commits,
> could I trouble you to fetch and cherry-pick them into `pu`, or would you
> prefer if I sent another iteration of `rebase-in-c-4-opts`?

If it were only about me, then the former if I can do my own pace is
easier.  If you promise that you won't complain if a few commits
lose the amlog notes by accident when such tree mangling is done,
that would be even better, but I'd be careful anyway.

I'd rather limit number of changes not seen on the list that come
into my tree, so it is likely that I'd parrot these fixup commits or
result of "commit --amend" to the list if we take that route.

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi Junio,
>
> On Wed, 10 Oct 2018, Junio C Hamano wrote:
>
>> We haven't seen much complaints and breakages reported against the
>> two big "rewrite in C" topics around "rebase"; perhaps it is a good
>> time to merge them to 'next' soonish to cook them for a few weeks
>> before moving them to 'master'?
>
> I would be in favor, as long as the fixup patches I have in Git for
> Windows made it in:
>
> https://github.com/git-for-windows/git/commit/6bc7024aecdb1aeb2760c519f7b26e6e5ef21051
>     fixup! builtin rebase: support `-C` and `--whitespace=<type>`
>
> https://github.com/git-for-windows/git/commit/1e6a1c510ffeae5bb0a4bda7f0528a8213728837
>     fixup! builtin rebase: support `--gpg-sign` option
>
> https://github.com/git-for-windows/git/commit/ddb6e5ca19d5cdd318bc4bcbb7f7f3fb0892c8cc
>     fixup! rebase -i: implement the main part of interactive rebase as a builtin
>
> https://github.com/git-for-windows/git/commit/2af24038a95a3879aa0c29d91a43180b9465247e
>     fixup! stash: convert apply to builtin
>
> It seems that Alban picked up the `rebase -i` one, but the other three
> have not made it into `pu` yet (the two `rebase` ones are really my fault,
> I did not yet find time).
>
> Speaking about the two `rebase` ones: they are simple fixup! commits,
> could I trouble you to fetch and cherry-pick them into `pu`, or would you
> prefer if I sent another iteration of `rebase-in-c-4-opts`?
>
> Ciao,
> Dscho

Re: builtin stash/rebase, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> https://github.com/git-for-windows/git/commit/6bc7024aecdb1aeb2760c519f7b26e6e5ef21051
>     fixup! builtin rebase: support `-C` and `--whitespace=<type>`

For c7ee2134d4 (rebase-in-c-4-opts); a single liner that is
obviously correct.

> https://github.com/git-for-windows/git/commit/1e6a1c510ffeae5bb0a4bda7f0528a8213728837
>     fixup! builtin rebase: support `--gpg-sign` option

For 28a02c5a79 (rebase-in-c-4-opts); the change looks correct (see a
separate message).

> https://github.com/git-for-windows/git/commit/ddb6e5ca19d5cdd318bc4bcbb7f7f3fb0892c8cc
>     fixup! rebase -i: implement the main part of interactive rebase as a builtin

You said Alban already has this in the update, which I took
yesterday, so I'll ignore this one.

> https://github.com/git-for-windows/git/commit/2af24038a95a3879aa0c29d91a43180b9465247e
>     fixup! stash: convert apply to builtin

I think we are expecting another round of update, so I'll ignore
this one for now, too.

> Speaking about the two `rebase` ones: they are simple fixup! commits,
> could I trouble you to fetch and cherry-pick them into `pu`, or would you
> prefer if I sent another iteration of `rebase-in-c-4-opts`?

Rebuilding 4 will involve rebuilding all the later ones anyway, so
I'll just try doing it myself and report back if I saw issues.
Thanks.

js/mingw-wants-vista-or-above, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Johannes Schindelin]

Hi Junio,

On Wed, 10 Oct 2018, Junio C Hamano wrote:

> * js/mingw-wants-vista-or-above (2018-10-04) 3 commits
>  - mingw: bump the minimum Windows version to Vista
>  - mingw: set _WIN32_WINNT explicitly for Git for Windows
>  - compat/poll: prepare for targeting Windows Vista
> 
>  The minimum version of Windows supported by Windows port fo Git is
>  now set to Vista.
> 
>  Will merge to 'next'.

Could I ask you to fast-track this to `master`? The code in `master`
unfortunately no longer compiles in a current Git for Windows SDK, meaning
that all of our Continuous Testing fails as long as these patches are not
merged.

I do not see how this could affect non-Windows builds, so everybody else
should be unaffected anyway.

Thanks,
Dscho

Re: js/mingw-wants-vista-or-above, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi Junio,
>
> On Wed, 10 Oct 2018, Junio C Hamano wrote:
>
>> * js/mingw-wants-vista-or-above (2018-10-04) 3 commits
>>  - mingw: bump the minimum Windows version to Vista
>>  - mingw: set _WIN32_WINNT explicitly for Git for Windows
>>  - compat/poll: prepare for targeting Windows Vista
>> 
>>  The minimum version of Windows supported by Windows port fo Git is
>>  now set to Vista.
>> 
>>  Will merge to 'next'.
>
> Could I ask you to fast-track this to `master`? The code in `master`
> unfortunately no longer compiles in a current Git for Windows SDK, meaning
> that all of our Continuous Testing fails as long as these patches are not
> merged.

Absolutely.  There is no point keeping it in 'pu', as nobody would
touch it in my tree until it hits 'next' and probably 'master' and
the change would get wider exposure to folks to whom it matters in
your tree anyway.

Thanks for pinging.

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Phillip Wood]

On 10/10/2018 06:43, Junio C Hamano wrote:
> 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.
> 
> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
>   - diff --color-moved: fix a memory leak
>   - diff --color-moved-ws: fix another memory leak
>   - diff --color-moved-ws: fix a memory leak
>   - diff --color-moved-ws: fix out of bounds string access
>   - diff --color-moved-ws: fix double free crash
> 
>   Various fixes to "diff --color-moved-ws".
> 
>   What's the status of this topic?

I think it is ready for next - Stefan was happy with the last iteration.

Best Wishes

Phillip

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Junio C Hamano]

Phillip Wood <phillip.wood@talktalk.net> writes:

> On 10/10/2018 06:43, Junio C Hamano wrote:
>> 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.
>>
>> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
>>   - diff --color-moved: fix a memory leak
>>   - diff --color-moved-ws: fix another memory leak
>>   - diff --color-moved-ws: fix a memory leak
>>   - diff --color-moved-ws: fix out of bounds string access
>>   - diff --color-moved-ws: fix double free crash
>>
>>   Various fixes to "diff --color-moved-ws".
>>
>>   What's the status of this topic?
>
> I think it is ready for next - Stefan was happy with the last iteration.

Thanks.

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Junio C Hamano]

Phillip Wood <phillip.wood@talktalk.net> writes:

> On 10/10/2018 06:43, Junio C Hamano wrote:
>> 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.
>>
>> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
>>   - diff --color-moved: fix a memory leak
>>   - diff --color-moved-ws: fix another memory leak
>>   - diff --color-moved-ws: fix a memory leak
>>   - diff --color-moved-ws: fix out of bounds string access
>>   - diff --color-moved-ws: fix double free crash
>>
>>   Various fixes to "diff --color-moved-ws".
>>
>>   What's the status of this topic?
>
> I think it is ready for next - Stefan was happy with the last iteration.

This is not about your fixes, but I was skimming the color-moved
support in general as a final sanity check to move this forward and
noticed that

	$ git diff --color-moved-ws=ignore-any master...

does not do anything interesting, which is broken at at least two
points.

 * There is no "ignore-any" supported by the feature---I think that
   the parser for the option should have noticed and barfed, but it
   did not.  It merely emitted a message to the standard output and
   let it scroll away with the huge diff before the reader noticed
   it.

 * After fixing ignore-any to one of the supported option
   (e.g. "ignore-all-spaces"), the color-moved feature still did not
   trigger.  I think the presence of --color-moved-ws by itself is a
   hint that the user wants --color-moved to be used.  If it turns
   out that there are some valid use cases where --color-moved-ws
   may have to be set but the color-moved feature should not be
   enabled, then

	diff --color-moved-ws=ignore-all-space --no-color-moved

   can be used to countermand this, of course.

Am I missing something or are these mere small sloppiness in the
current code?

[PATCH] diff.c: die on unknown color-moved ws mode

[Stefan Beller]

Noticed-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
--- 


   There is no "ignore-any" supported by the feature---I think that
   the parser for the option should have noticed and barfed, but it
   did not.  It merely emitted a message to the standard output and
   let it scroll away with the huge diff before the reader noticed
   it.
   
Addressed in this patch.

   Am I missing something [...] ?

Note that this parsing is used for both the parsing from command line
as well as options, i.e.

  git config diff.colorMovedWS asdf
  git format-patch HEAD^
fatal: ignoring unknown color-moved-ws mode 'asdf'
  git config --unset diff.colorMovedWS

(format-patch parses these color specific things, but doesn't apply it)
   
 diff.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/diff.c b/diff.c
index 145cfbae59..bdf4535d69 100644
--- a/diff.c
+++ b/diff.c
@@ -313,7 +313,7 @@ static int parse_color_moved_ws(const char *arg)
 		else if (!strcmp(sb.buf, "allow-indentation-change"))
 			ret |= COLOR_MOVED_WS_ALLOW_INDENTATION_CHANGE;
 		else
-			error(_("ignoring unknown color-moved-ws mode '%s'"), sb.buf);
+			die(_("ignoring unknown color-moved-ws mode '%s'"), sb.buf);
 
 		strbuf_release(&sb);
 	}
-- 
2.19.0

Re: [PATCH] diff.c: die on unknown color-moved ws mode

[Stefan Beller]

On Thu, Oct 11, 2018 at 3:59 PM Stefan Beller <sbeller@google.com> wrote:

> -                       error(_("ignoring unknown color-moved-ws mode '%s'"), sb.buf);
> +                       die(_("ignoring unknown color-moved-ws mode '%s'"), sb.buf);

s/ignoring// as it was sent in a haste.

Re: [PATCH] diff.c: die on unknown color-moved ws mode

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> Noticed-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> --- 
>
>
>    There is no "ignore-any" supported by the feature---I think that
>    the parser for the option should have noticed and barfed, but it
>    did not.  It merely emitted a message to the standard output and
>    let it scroll away with the huge diff before the reader noticed
>    it.
>    
> Addressed in this patch.
>
>    Am I missing something [...] ?
>
> Note that this parsing is used for both the parsing from command line
> as well as options, i.e.

Hmph, is it our convention for a value that is not yet known to the
current version of Git found in a configuration file to cause it to
die?  I somehow thought that command line options are checked more
strictly and configuration variables are parsed more leniently.

If that is the case, the place that dies need to be raised in the
callchain; iow, instead of dying inside the parser, it is necessary
to let it only detect a problem and allow the caller to decide what
to do with the problem, I would think.

>   git config diff.colorMovedWS asdf
>   git format-patch HEAD^
> fatal: ignoring unknown color-moved-ws mode 'asdf'
>   git config --unset diff.colorMovedWS



>
> (format-patch parses these color specific things, but doesn't apply it)
>    
>  diff.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/diff.c b/diff.c
> index 145cfbae59..bdf4535d69 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -313,7 +313,7 @@ static int parse_color_moved_ws(const char *arg)
>  		else if (!strcmp(sb.buf, "allow-indentation-change"))
>  			ret |= COLOR_MOVED_WS_ALLOW_INDENTATION_CHANGE;
>  		else
> -			error(_("ignoring unknown color-moved-ws mode '%s'"), sb.buf);
> +			die(_("ignoring unknown color-moved-ws mode '%s'"), sb.buf);
>  
>  		strbuf_release(&sb);
>  	}

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Stefan Beller]

On Thu, Oct 11, 2018 at 3:41 PM Junio C Hamano <gitster@pobox.com> wrote:

>  * After fixing ignore-any to one of the supported option
>    (e.g. "ignore-all-spaces"), the color-moved feature still did not
>    trigger.  I think the presence of --color-moved-ws by itself is a
>    hint that the user wants --color-moved to be used.  If it turns
>    out that there are some valid use cases where --color-moved-ws
>    may have to be set but the color-moved feature should not be
>    enabled, then
>
>         diff --color-moved-ws=ignore-all-space --no-color-moved
>
>    can be used to countermand this, of course.

I had the same idea for --color-moved to imply --color, but there
we had some issues with configured settings, as we do not want
diff.colorMoved to imply colored patches, but only when given on
the command line.

I think we should add these tweaks, such that
color-moved-ws implies color-moved (both config and CLI options)
and --color-moved implies --color (command line only)

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> I think we should add these tweaks, such that
> color-moved-ws implies color-moved (both config and CLI options)
> and --color-moved implies --color (command line only)

I am not sure what you mean by "both config and".  I'd find it
entirely sensible for a user to say "I do not always use the
color-moved option, but when I do, I want it to handle the
whitespace differences this way by default".

So presence of diff.colorMovedWS configuration variable should never
trigger the color-moved feature by itself, I would think.

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Phillip Wood]

On 11/10/2018 23:40, Junio C Hamano wrote:
> Phillip Wood <phillip.wood@talktalk.net> writes:
> 
>> On 10/10/2018 06:43, Junio C Hamano wrote:
>>> 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.
>>>
>>> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
>>>   - diff --color-moved: fix a memory leak
>>>   - diff --color-moved-ws: fix another memory leak
>>>   - diff --color-moved-ws: fix a memory leak
>>>   - diff --color-moved-ws: fix out of bounds string access
>>>   - diff --color-moved-ws: fix double free crash
>>>
>>>   Various fixes to "diff --color-moved-ws".
>>>
>>>   What's the status of this topic?
>>
>> I think it is ready for next - Stefan was happy with the last iteration.
> 
> This is not about your fixes, but I was skimming the color-moved
> support in general as a final sanity check to move this forward and
> noticed that
> 
> 	$ git diff --color-moved-ws=ignore-any master...
> 
> does not do anything interesting, which is broken at at least two
> points.
> 
>  * There is no "ignore-any" supported by the feature---I think that
>    the parser for the option should have noticed and barfed, but it
>    did not.  It merely emitted a message to the standard output and
>    let it scroll away with the huge diff before the reader noticed
>    it.

It would be nice if the parsing used starts_with(option_name, user_text)
rather than strcmp() as well. Also I think --color-moved=no is valid as
a synonym of --no-color-moved but --color-moved-ws=no is not supported.

>  * After fixing ignore-any to one of the supported option
>    (e.g. "ignore-all-spaces"), the color-moved feature still did not
>    trigger.  I think the presence of --color-moved-ws by itself is a
>    hint that the user wants --color-moved to be used.  If it turns
>    out that there are some valid use cases where --color-moved-ws
>    may have to be set but the color-moved feature should not be
>    enabled, then
> 
> 	diff --color-moved-ws=ignore-all-space --no-color-moved
> 
>    can be used to countermand this, of course.
> 
> Am I missing something or are these mere small sloppiness in the
> current code?
> 
> 
> 

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Junio C Hamano]

Phillip Wood <phillip.wood@talktalk.net> writes:

> It would be nice if the parsing used starts_with(option_name, user_text)
> rather than strcmp() as well. Also I think --color-moved=no is valid as
> a synonym of --no-color-moved but --color-moved-ws=no is not supported.

I am not sure about starts_with().  Do you mean we should accept
"--color-mo", as that is a prefix of "--color-moved" that is not
shared with any existing option, until we gain a different option
"--color-more"?

If you mean "--color-moved-ws=no" (or "--no-color-moved-ws") as a
way to countermand an earlier --color-moved-ws=<something> on the
command line, I fully agree that it is a good idea.

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Phillip Wood]

On 12/10/2018 14:36, Junio C Hamano wrote:
> Phillip Wood <phillip.wood@talktalk.net> writes:
> 
>> It would be nice if the parsing used starts_with(option_name, user_text)
>> rather than strcmp() as well. Also I think --color-moved=no is valid as
>> a synonym of --no-color-moved but --color-moved-ws=no is not supported.
> 
> I am not sure about starts_with().  Do you mean we should accept
> "--color-mo", as that is a prefix of "--color-moved" that is not
> shared with any existing option, until we gain a different option
> "--color-more"?

I was thinking of the option arguments rather than the option names 
although being able to abbreviate the names in the same way as the 
commands that parse_options() would be good too (I seem to remember 
someone saying they had some rough patches to use parse_options() for 
diff and log in a discussion of adding completion support to 
parse_options())

> If you mean "--color-moved-ws=no" (or "--no-color-moved-ws") as a
> way to countermand an earlier --color-moved-ws=<something> on the
> command line, I fully agree that it is a good idea.

Oh I assumed --no-color-moved-ws was allowed but it isn't it. Allowing 
--color-moved-ws=no as well would match what is allowed for 
--color-moved. I'll try and look at that.

Best Wishes

Phillip

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Stefan Beller]

On Tue, Oct 16, 2018 at 6:39 AM Phillip Wood <phillip.wood@talktalk.net> wrote:
> > If you mean "--color-moved-ws=no" (or "--no-color-moved-ws") as a
> > way to countermand an earlier --color-moved-ws=<something> on the
> > command line, I fully agree that it is a good idea.
>
> Oh I assumed --no-color-moved-ws was allowed but it isn't it. Allowing
> --color-moved-ws=no as well would match what is allowed for
> --color-moved. I'll try and look at that.

Thanks for taking a look!
Stefan

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Thomas Gummerer]

On 10/10, Junio C Hamano wrote:
> * ps/stash-in-c (2018-08-31) 20 commits
>  - stash: replace all `write-tree` child processes with API calls
>  - stash: optimize `get_untracked_files()` and `check_changes()`
>  - stash: convert `stash--helper.c` into `stash.c`
>  - stash: convert save to builtin
>  - stash: make push -q quiet
>  - stash: convert push to builtin
>  - stash: convert create to builtin
>  - stash: convert store to builtin
>  - stash: mention options in `show` synopsis
>  - stash: convert show to builtin
>  - stash: convert list to builtin
>  - stash: convert pop to builtin
>  - stash: convert branch to builtin
>  - stash: convert drop and clear to builtin
>  - stash: convert apply to builtin
>  - stash: add tests for `git stash show` config
>  - stash: rename test cases to be more descriptive
>  - stash: update test cases conform to coding guidelines
>  - stash: improve option parsing test coverage
>  - sha1-name.c: add `get_oidf()` which acts like `get_oid()`
> 
>  "git stash" rewritten in C.
> 
>  Undecided.  This also has been part of my personal build.  I do not
>  offhand recall if this also had the same exposure to the end users
>  as "rebase" and "rebase -i".  I am tempted to merge this to 'next'
>  soonish.
> 
>  Opinions?

There was a v9 of this series [*1*], which hasn't been picked up yet.
Was that intentional, or an oversight?

I left some comments on that iteration.  Some were just style nits,
but I think at least [*2*] should be addressed before we merge this
down to master, not sure if any of my other comments apply to v8 as
well.  I'm happy to send fixup patches, or a patches on top of
this series for that and my other comments, should they apply to v8,
or wait for Paul-Sebastian to send a re-roll.  What do you prefer?

[*1*]: <cover.1537913094.git.ungureanupaulsebastian@gmail.com>
[*2*]: <20180930174848.GE2253@hank.intra.tgummerer.com>

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Junio C Hamano]

Thomas Gummerer <t.gummerer@gmail.com> writes:

> There was a v9 of this series [*1*], which hasn't been picked up yet.
> Was that intentional, or an oversight?

;-) Yes, I often miss patches that are buried in other discussions,
but this time, it was quite deliberate.  I saw comments that pointed
out at least one thing that needs to be fixed before the series can
move forward, so I skipped that iteration, anticipating another
round of update.

Also, I was waiting for [*3*] to be answered.

> I left some comments on that iteration.  Some were just style nits,
> but I think at least [*2*] should be addressed before we merge this
> down to master, not sure if any of my other comments apply to v8 as
> well.  I'm happy to send fixup patches, or a patches on top of
> this series for that and my other comments, should they apply to v8,
> or wait for Paul-Sebastian to send a re-roll.  What do you prefer?

The ideal from my point of view is to see responses to your comments
in the original thread (which is about 1300 messages ago in the list
archive by now) by Paul-Sebastian, possibly responded by you and/or
others, resulting in a concensus on what the right update for the
patches should be, finally followed by v10, which hopefully would be
the final one.

> [*1*]: <cover.1537913094.git.ungureanupaulsebastian@gmail.com>
> [*2*]: <20180930174848.GE2253@hank.intra.tgummerer.com>

[*3*] <xmqq8t3oksve.fsf@gitster-ct.c.googlers.com>

`--rebase-merges' still failing badly

[Michael Witten]

On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote:

> We haven't seen  much complaints and breakages  reported against the
> two big "rewrite in C" topics  around "rebase"; perhaps it is a good
> time to merge  them to 'next' soonish  to cook them for  a few weeks
> before moving them to 'master'?

In my opinion, the `--rebase-merges' feature has been broken since the
beginning, and the builtin version should  be fixed before it is moved
ahead. In short: "labels" are brittle; see below for tests.

Also, here are some quick *additional* thoughts:

    * Labels should be simply "r0", "r1", ... "rN".

          * The current, long label names are just cumbersome.
          * The embedded comments are already more than enough.
          * "r" is short for "revision" or "reset" or "remember", etc.
          * "r" is  located on a  QWERTY keyboard such that  it's very
            easy to type "rN", where "N" is a number.

    * Why is the command "label" and not "branch"? Every other related
      command looks  like a normal  git command: "reset"  and "merge".
      Make it "branch".

    * In my experience, there's a lot of this boiler plate:

          pick 12345
          label r1
          reset r0
          merge r1

      How about instead, use git's existing ideas:

          pick 12345
          reset r0
          merge ORIG_HEAD

      Or, maybe git in general  should treat `-' as `ORIG_HEAD' (which
      would be similar to how `git checkout' understands `-'), thereby
      allowing a very quick idiomatic string of commands:

          pick 12345
          reset r0
          merge -

      In truth, I don't really know the semantics of `ORIG_HEAD', so
      maybe those should be nailed down and documented more clearly;
      I would like it to work as in the following:

          pick 12345
                     # label r1 (pretend)
          reset r0   # Store r1 in ORIG_HEAD
          pick 67890 # Do NOT touch ORIG_HEAD
          merge -    # Same as merge -C abcde r1

      Anyway, this  kind of unspoken  behavior would make  *writing* a
      new history by hand much more pleasant.

    * Why not just `--merges' instead of `--rebase-merges'? Or, better
      yet,  just make  it  the default  behavior;  the special  option
      should instead be:

          --flatten

      This option would simply tell `git rebase' to prepare an initial
      todo list without merges.

Thanks for this great feature.

I'm only complaining so much because it's such a useful feature, and I
want it  to be  even better, because  I'll  probably use it  A LOT; it
should have been available since the start as a natural consequence of
the way git works.

Sincerely,
Michael Witten

---------------

Unfortunately,   both  the   legacy   version  and   the  rewrite   of
`--rebase-merges'  display  a  bug  that  makes  this  feature  fairly
unusable in  practice; it tries  to create  a "label" (i.e.,  a branch
name) from a commit log summary  line, and the result is often invalid
(or just  plain irritating to work  with). In particular, it  fails on
typical characters, including at least these:

    :/\?.*[]

To see this, first define some POSIX shell functions:

    test()
    {
        (
            set -e
            summary=$1
            d=/tmp/repo ##### WARNING. CHANGE IF NECESSARY.
            rm -rf "$d"; mkdir -p "$d"; cd "$d"
            git init -q
            echo a > a; git add a; git commit -q -m a
            git branch base
            echo b > b; git add b; git commit -q -m b
            git reset -q --hard HEAD^
            git merge -q --no-ff -m "$summary" ORIG_HEAD
            git log --graph --oneline
            git rebase --rebase-merges base
        ); status=$?
        echo
        return "$status"
    }

    Test()
    {
        if test "$@" 1>/dev/null 2>&1; then
            echo '    good'; return 0
        else
            echo '    fail'; return 1
        fi
    }

Then, try various commit summaries (see below for results):

    test c
    test 'combine these into a merge: a and b'
    Test ab:
    Test a:b
    Test :
    Test a/b
    Test 'Now supports /regex/'
    Test ab/
    Test /ab
    Test /
    Test 'a\b'
    Test '\'
    Test 'Maybe this works?'
    Test '?'
    Test 'This does not work.'
    Test 'This works. Strange!'
    Test .git
    Test .
    Test 'Cast each pointer to *void'
    Test '*'
    Test 'return a[1] not a[0]'
    Test '[ does not work'
    Test '['
    Test '] does work'
    Test ']'

Here are the results of pasting the above commands into my terminal:

    $ test c
    warning: templates not found in ../install/share/git-core/templates
    *   1992d07 (HEAD -> master) c
    |\
    | * 34555b5 b
    |/
    * 338db9b (base) a
    Successfully rebased and updated refs/heads/master.

    $ test 'combine these into a merge: a and b'
    warning: templates not found in ../install/share/git-core/templates
    *   4202c49 (HEAD -> master) combine these into a merge: a and b
    |\
    | * 34555b5 b
    |/
    * 338db9b (base) a
    error: refusing to update ref with bad name 'refs/rewritten/combine-these-into-a-merge:-a-and-b'
    hint: Could not execute the todo command
    hint:
    hint:     label combine-these-into-a-merge:-a-and-b
    hint:
    hint: It has been rescheduled; To edit the command before continuing, please
    hint: edit the todo list first:
    hint:
    hint:     git rebase --edit-todo
    hint:     git rebase --continue

    $ Test ab:
        fail
    $ Test a:b
        fail
    $ Test :
        fail
    $ Test a/b
        good
    $ Test 'Now supports /regex/'
        fail
    $ Test ab/
        fail
    $ Test /ab
        fail
    $ Test /
        fail
    $ Test 'a\b'
        fail
    $ Test '\'
        fail
    $ Test 'Maybe this works?'
        fail
    $ Test '?'
        fail
    $ Test 'This does not work.'
        fail
    $ Test 'This works. Strange!'
        good
    $ Test .git
        fail
    $ Test .
        fail
    $ Test 'Cast each pointer to *void'
        fail
    $ Test '*'
        fail
    $ Test 'return a[1] not a[0]'
        fail
    $ Test '[ does not work'
        fail
    $ Test '['
        fail
    $ Test '] does work'
        good
    $ Test ']'
        good

Re: `--rebase-merges' still failing badly

[Michael Witten]

On Wed, 10 Oct 2018 18:51:17 -0000, Michael Witten wrote:

>         merge -    # Same as merge -C abcde r1

That should be:

          merge -    # Same as `merge r1'

Re: `--rebase-merges' still failing badly

[Junio C Hamano]

Michael Witten <mfwitten@gmail.com> writes:

> On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote:
>
>> We haven't seen  much complaints and breakages  reported against the
>> two big "rewrite in C" topics  around "rebase"; perhaps it is a good
>> time to merge  them to 'next' soonish  to cook them for  a few weeks
>> before moving them to 'master'?
>
> In my opinion, the `--rebase-merges' feature has been broken since the
> beginning, and the builtin version should  be fixed before it is moved
> ahead.

I'll omit the remainder of the message not because I disagree with
your suggested improvements to "rebase-merges" (that conversation
should happen primarily with Dscho), but because I need to react to
the above three lines.

If "rebase-merges" has been broken since the beginning, as long as
the "rewrite in C" topics around "rebase" do not make it even worse,
I do not think it is a good move to block the topics moving forward.
If the feature were so broken that it is not practically useful,
then people wouldn't be using it in the versions of Git before the
rewrite, so it won't harm anybody if the same feature in the rewritten
version is equally (or even more severely) broken, as long as the
other parts of the feature works at least equally well compared to
the older version.

We are not in the business of hostage taking.

What *should* block the rewrited version is a regression,
i.e. something that used to work well no longer works or works
differently in such a way that established workflows need to be
adjusted.

In any case, suggestions to improve "rebase-merges" is a very much
welcome thing to be discussed on the list, so thanks for raising the
issue.  What I wanted to say is that I do not think that is a reason
to keep "rewrite in C" waiting in 'pu'.

Re: `--rebase-merges' still failing badly

[Michael Witten]

On Thu, 11 Oct 2018 08:01:40 +0900, Junio wrote:

> Michael Witten <mfwitten@gmail.com> writes:
>
>> On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote:
>>
>>> We haven't seen  much complaints and breakages  reported against the
>>> two big "rewrite in C" topics  around "rebase"; perhaps it is a good
>>> time to merge  them to 'next' soonish  to cook them for  a few weeks
>>> before moving them to 'master'?
>>
>> In my opinion, the `--rebase-merges' feature has been broken since the
>> beginning, and the builtin version should  be fixed before it is moved
>> ahead.
>
> [...]
>
> If "rebase-merges" has been broken since  the beginning, as long as the
> "rewrite in C" topics  around "rebase" do not make it  even worse, I do
> not think it is a good move  to block the topics moving forward. If the
> feature were so  broken that it is not practically  useful, then people
> wouldn't be using it  in the versions of Git before  the rewrite, so it
> won't harm  anybody if  the same  feature in  the rewritten  version is
> equally (or even  more severely) broken, as long as  the other parts of
> the feature works at least equally well compared to the older version.
>
> We are not in the business of hostage taking.
>
> What  *should*  block  the  rewrited  version  is  a  regression,  i.e.
> something that used  to work well no longer works  or works differently
> in such a way that established workflows need to be adjusted.
>
> [...] I do not think that is a reason to keep "rewrite in C" waiting in
> 'pu'.

* Your logic  is appealing,  and I  nearly pursuaded  myself by  the same
  reasoning to submit my email as  a separate discussion, as you suggest.
  However, what convinced me otherwise is the following:

      The  closer you  move  the rewrite  to  a fast-forward-only  public
      branch  name, the  more  likely downstream  projects  are going  to
      set  up  new,  long-lived  releases around  this  very  useful  but
      nevertheless broken feature.

  The moment you announce a new release, there are going to be a bunch of
  people who grab that release and then  NEVER look back, and so the rest
  of us will be stuck with this problem for who knows how long.

  So, not only is this an appeal  to the authors to fix this problem, but
  its also  an appeal  to you to  make sure that the  next  major release
  includes the fix.

* Also, I say the following without irony or tongue in cheek:

      Maybe, no one  has complained  because  few people  are using  this
      feature yet, or  their commit summaries are  simplistic, or they've
      got workarounds (as I've got).

  Not  only must  this feature  be turned  on explicitly,  but `git'  has
  existed for  over a decade  *without* it;  users who are  interested in
  sophisticated management of commit history have already developed other
  ways  to achieve  the  same result  (I  know I  did),  or their  commit
  messages are  so simplistic that  the bug  is never triggered,  or they
  just plan around it by automatically running a quick search/replace for
  the offending characters or for the irritating "labels".

  If the last decade has shown  us anything, it's that git's fundamentals
  are  so good  that programmers  can get  around any  bug on  their own,
  without having to appeal to others  for help. And, what is a programmer
  if not someone who is used to making things Just Work [Damnit]?

  As an illustration,  consider the recent `break' command  that is being
  added to the repertoire of `git  rebase -i'. Hell, I (and probably many
  others) have been doing that for YEARS with:

      x false

  No need for a "new" command. I bet that 10 years from now,  people will
  *still* be using their own ways,  and will *still* be totally oblivious
  to the existence of `break'.

  That is to say, I wouldn't put much faith in the degree to which people
  report issues. The programming world has a lot of itchy backs, and just
  as many personal inventions for scratching them.

As always, thanks for taking the time to review everyone's input.

Sincerely,
Michael Witten

Re: `--rebase-merges' still failing badly

[Johannes Schindelin]

Hi Michael,

On Wed, 10 Oct 2018, Michael Witten wrote:

> In my opinion, the `--rebase-merges' feature has been broken since the
> beginning, and the builtin version should  be fixed before it is moved
> ahead.

Everybody is entitled to an opinion. My opinion differs from yours, and I
am a heavy user of `git rebase -kir`.

The `--rebase-merges` feature is not without problems, of course. I can
name a couple of bugs, but I have a hunch that it is more efficient for me
to just fix them.

> In short: "labels" are brittle; see below for tests.

Sure, let's improve them.

> Also, here are some quick *additional* thoughts:
> 
>     * Labels should be simply "r0", "r1", ... "rN".

That would not be an improvement.

The *interactive* version of `--rebase-merges` is what I use extensively
to juggle Git for Windows' branch thicket. It would be really bad if I had
to somehow map those label names in my head, rather than having the
intuitively-understood labels.

I would understand if you suggested to try to come up with a better naming
than `branch-point-<n>`. But `r<n>`? That's worse than the current state.
By a lot.

>     * Why is the command "label" and not "branch"?

Because it is more versatile than just a branch. It is also branch points.
As a matter of fact, the very first statement is about the `onto` label,
which is not a branch.

>     * In my experience, there's a lot of this boiler plate:
> 
>           pick 12345
>           label r1
>           reset r0
>           merge r1
> 
>       How about instead, use git's existing ideas:
> 
>           pick 12345
>           reset r0
>           merge ORIG_HEAD

Too magic. And you cannot change it easily. I had this very real example,
a couple of times yesterday: A merge was in one of the "branches", and
needed to be moved out of it:

	pick abc
	label branch-point
	merge -C 0123 topic
	pick def
	label bug-fix

	reset branch-point
	merge -C 4567 bug-fix

This `merge -C 0123 topic` needed to be moved before the branch point.

Another example where the explicit labeling comes in *real* handy is when
I made a Pull Request in Git for Windows ready for contribution to core
Git. These Pull Requests are normally based on `master`, because that is
what the best PR flow is: you based your contributions as close to the tip
as possible, to avoid merge conflicts (and to test as close to the real,
after-merge thing). This would look like this:

	label branch-point
	pick 123
	pick 456
	label pr-0815

	reset branch-point
	merge -C abc pr-0815

Now, to prepare this for core Git, I have to graft this PR onto the
`master` of *upstream*, in our case I would use the `onto` label for that,
by inserting a `reset onto` just before `pick 123`.

So you see, the current, non-implicit, but very much explicit syntax,
makes all of these tasks *quite* easy, and more importantly,
straight-forward: I did not have to explain this to anyone who I needed to
teach how this works.

Remember: the syntax of the todo list is not optimized to be short. It is
optimized to be *editable*. I need to have a very easy way to juggle
criss-cross-merging branch thickets. And the current syntax, while
chattier than you would like, does the job. Pretty well, even.

>     * Why not just `--merges' instead of `--rebase-merges'?

This ship has sailed. It is pointless to discuss this now.

Besides, I believe that in your quest to shorten things, you unfortunately
shortened things too much: it is no longer clear what "merges" means in
the context of `--merges`.

> Unfortunately,   both  the   legacy   version  and   the  rewrite   of
> `--rebase-merges'  display  a  bug  that  makes  this  feature  fairly
> unusable in  practice;

You will be surprised just how much I would embrace bug fixes, once you
provide any.

> it tries  to create  a "label" (i.e.,  a branch name) from a commit log
> summary  line, and the result is often invalid (or just  plain
> irritating to work  with). In particular, it  fails on typical
> characters, including at least these:
> 
>     :/\?.*[]

And of course those are not the only ones. The trick is to reduce runs of
disallowed characters to dashes, as is already done with spaces.

Ciao,
Johannes

> 
> To see this, first define some POSIX shell functions:
> 
>     test()
>     {
>         (
>             set -e
>             summary=$1
>             d=/tmp/repo ##### WARNING. CHANGE IF NECESSARY.
>             rm -rf "$d"; mkdir -p "$d"; cd "$d"
>             git init -q
>             echo a > a; git add a; git commit -q -m a
>             git branch base
>             echo b > b; git add b; git commit -q -m b
>             git reset -q --hard HEAD^
>             git merge -q --no-ff -m "$summary" ORIG_HEAD
>             git log --graph --oneline
>             git rebase --rebase-merges base
>         ); status=$?
>         echo
>         return "$status"
>     }
> 
>     Test()
>     {
>         if test "$@" 1>/dev/null 2>&1; then
>             echo '    good'; return 0
>         else
>             echo '    fail'; return 1
>         fi
>     }
> 
> Then, try various commit summaries (see below for results):
> 
>     test c
>     test 'combine these into a merge: a and b'
>     Test ab:
>     Test a:b
>     Test :
>     Test a/b
>     Test 'Now supports /regex/'
>     Test ab/
>     Test /ab
>     Test /
>     Test 'a\b'
>     Test '\'
>     Test 'Maybe this works?'
>     Test '?'
>     Test 'This does not work.'
>     Test 'This works. Strange!'
>     Test .git
>     Test .
>     Test 'Cast each pointer to *void'
>     Test '*'
>     Test 'return a[1] not a[0]'
>     Test '[ does not work'
>     Test '['
>     Test '] does work'
>     Test ']'
> 
> Here are the results of pasting the above commands into my terminal:
> 
>     $ test c
>     warning: templates not found in ../install/share/git-core/templates
>     *   1992d07 (HEAD -> master) c
>     |\
>     | * 34555b5 b
>     |/
>     * 338db9b (base) a
>     Successfully rebased and updated refs/heads/master.
> 
>     $ test 'combine these into a merge: a and b'
>     warning: templates not found in ../install/share/git-core/templates
>     *   4202c49 (HEAD -> master) combine these into a merge: a and b
>     |\
>     | * 34555b5 b
>     |/
>     * 338db9b (base) a
>     error: refusing to update ref with bad name 'refs/rewritten/combine-these-into-a-merge:-a-and-b'
>     hint: Could not execute the todo command
>     hint:
>     hint:     label combine-these-into-a-merge:-a-and-b
>     hint:
>     hint: It has been rescheduled; To edit the command before continuing, please
>     hint: edit the todo list first:
>     hint:
>     hint:     git rebase --edit-todo
>     hint:     git rebase --continue
> 
>     $ Test ab:
>         fail
>     $ Test a:b
>         fail
>     $ Test :
>         fail
>     $ Test a/b
>         good
>     $ Test 'Now supports /regex/'
>         fail
>     $ Test ab/
>         fail
>     $ Test /ab
>         fail
>     $ Test /
>         fail
>     $ Test 'a\b'
>         fail
>     $ Test '\'
>         fail
>     $ Test 'Maybe this works?'
>         fail
>     $ Test '?'
>         fail
>     $ Test 'This does not work.'
>         fail
>     $ Test 'This works. Strange!'
>         good
>     $ Test .git
>         fail
>     $ Test .
>         fail
>     $ Test 'Cast each pointer to *void'
>         fail
>     $ Test '*'
>         fail
>     $ Test 'return a[1] not a[0]'
>         fail
>     $ Test '[ does not work'
>         fail
>     $ Test '['
>         fail
>     $ Test '] does work'
>         good
>     $ Test ']'
>         good
> 

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Stefan Beller]

> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
>  - diff --color-moved: fix a memory leak
>  - diff --color-moved-ws: fix another memory leak
>  - diff --color-moved-ws: fix a memory leak
>  - diff --color-moved-ws: fix out of bounds string access
>  - diff --color-moved-ws: fix double free crash
>
>  Various fixes to "diff --color-moved-ws".
>
>  What's the status of this topic?

Per [1] ("The whole series is
Reviewed-by: Stefan Beller <sbeller@google.com>"),
I would suggest merging to 'next'.

[1] https://public-inbox.org/git/CAGZ79kbamUK=d+-ejy9vopDiVZF7OVOngz1Zx9y04VR3HnmoXg@mail.gmail.com/

> * sb/strbuf-h-update (2018-09-29) 1 commit
>  - strbuf.h: format according to coding guidelines
>
>  Code clean-up to serve as a BCP example.
>
>  What's the status of this one after the discussion thread stopped here?
>  cf. <CAGZ79kbV6QjsFKcD2uG_P9j1AvzSNQSi-_jXGQ9w0YU9fjhEGg@mail.gmail.com>

I was waiting for more discussion and stricter guidelines,
which never happened.

The only controversial issue about this patch is whether we want
to name all parameters or only when we feel like it.

Peff did not seem to care about this particular detail
https://public-inbox.org/git/20180929073827.GD2174@sigill.intra.peff.net/

You suggested to embrace it further and use caps for the parameter
names in the docs comment.
https://public-inbox.org/git/xmqq8t3lb8uu.fsf@gitster-ct.c.googlers.com/

The patch as-is just adds names everywhere.
I'd be happy to resend with either
(a) not enforcing names everywhere, but only as needed or
(b) having names everywhere, capitalizing them NAMES in
    the doc comment.

I am tempted to ask for
(c) take as-is, defer the rewording of doc strings for a follow up patch.

> * sb/grep-submodule-cleanup (2018-10-10) 1 commit
>  - builtin/grep.c: remove superfluous submodule code
>
>  Code clean-up.
>
>  cf. <20181010001037.74709-1-jonathantanmy@google.com>

Will resend.


> * bw/submodule-name-to-dir (2018-08-10) 2 commits
>  - submodule: munge paths to submodule git directories
>  - submodule: create helper to build paths to submodule gitdirs
>
>  In modern repository layout, the real body of a cloned submodule
>  repository is held in .git/modules/ of the superproject, indexed by
>  the submodule name.  URLencode the submodule name before computing
>  the name of the directory to make sure they form a flat namespace.
>
>  Kicked back to 'pu', expecting further work on the topic.
>  cf. <CAGZ79kYnbjaPoWdda0SM_-_X77mVyYC7JO61OV8nm2yj3Q1OvQ@mail.gmail.com>

Thanks.

>
> * sb/submodule-move-head-with-corruption (2018-08-28) 2 commits
>  - submodule.c: warn about missing submodule git directories
>  - t2013: add test for missing but active submodule
>
>  Will discard and wait for a cleaned-up rewrite.
>  cf. <20180907195349.GA103699@aiede.svl.corp.google.com>

Yeah I think discarding this is the right move.

> * sb/submodule-recursive-fetch-gets-the-tip (2018-09-12) 9 commits
>  - builtin/fetch: check for submodule updates for non branch fetches
>  - fetch: retry fetching submodules if sha1 were not fetched
>  - submodule: fetch in submodules git directory instead of in worktree
>  - submodule.c: do not copy around submodule list
>  - submodule: move global changed_submodule_names into fetch submodule struct
>  - submodule.c: sort changed_submodule_names before searching it
>  - submodule.c: fix indentation
>  - sha1-array: provide oid_array_filter
>  - string-list: add string_list_{pop, last} functions
>
>  "git fetch --recurse-submodules" may not fetch the necessary commit
>  that is bound to the superproject, which is getting corrected.
>
>  Expecting a reroll.
>  cf. <b16af8c0-0435-0de4-ed6c-53888d6190af@ramsayjones.plus.com>

is fixed in
https://public-inbox.org/git/20180917213559.126404-7-sbeller@google.com/

>  cf. <CAGZ79kbavjVbTqXsmtjW6=jhkq47_p3mc6=92xOp4_mfhqDtvw@mail.gmail.com>

That is fixed locally

>  cf. <CAGZ79kZKKf9N8yx9EuCRZhrZS_mA2218PouEG7aHDhK2bJGEdA@mail.gmail.com>

That has been addressed via
https://public-inbox.org/git/20180925194755.105578-1-sbeller@google.com/

Will resend after a local review.

> * pk/rebase-in-c-6-final (2018-10-09) 1 commit
>  - rebase: default to using the builtin rebase
>  (this branch uses ag/rebase-i-in-c, js/rebase-in-c-5.5-work-with-rebase-i-in-c, pk/rebase-in-c, pk/rebase-in-c-2-basic, pk/rebase-in-c-3-acts, pk/rebase-in-c-4-opts and pk/rebase-in-c-5-test; is tangled with ag/sequencer-reduce-rewriting-todo, jc/rebase-in-c-5-test-typofix and js/rebase-i-break.)
>
>  The final step of rewriting "rebase -i" in C.
>
>  Undecided.
>  I've been using this (i.e. the whole "rebase -i" and "rebase"
>  rewritten in C) in my personal build, and I also know users on
>  Windows port have been using it with the last feature release.  I
>  am tempted to merge the whole thing to 'next' soonish.
>
>  Opinions?  It's the last chance to remove any existing and avoid
>  any future "oops, that was wrong, and here is a fix-up"
>  embarrassment in these topics.

Yes, please merge to next.

Stefan

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

>> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
> I would suggest merging to 'next'.

OK.

>> * sb/strbuf-h-update (2018-09-29) 1 commit
> The patch as-is just adds names everywhere.
> I'd be happy to resend with either
> (a) not enforcing names everywhere, but only as needed or
> (b) having names everywhere, capitalizing them NAMES in
>     the doc comment.
>
> I am tempted to ask for
> (c) take as-is, defer the rewording of doc strings for a follow up patch.

As long as the planned update eventually comes before all of us
forget, (c) is fine by me.  I'll mark it to be merged to 'next' for
now, and follow through that plan, unless somebody else stops me
before it happens.

>> * sb/submodule-recursive-fetch-gets-the-tip (2018-09-12) 9 commits
> Will resend after a local review.

OK.

Thanks for helping me in updating the status for various topics.

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Tim Schumacher]

On 10.10.18 07:43, Junio C Hamano wrote:
> * ts/alias-of-alias (2018-09-17) 3 commits
>    (merged to 'next' on 2018-10-09 at ac19b4730b)
>   + t0014: introduce an alias testing suite
>   + alias: show the call history when an alias is looping
>   + alias: add support for aliases of an alias
>
>   An alias that expands to another alias has so far been forbidden,
>   but now it is allowed to create such an alias.
>
>   Will merge to 'master'.
Oh well, I still have the changed comment stored locally.
I guess that has to wait for another time.

Anyways, thanks for pulling this in.

PS: I hope that this E-Mail is formatted correctly. Thunderbird
received an update and now it doesn't show me plain text when
composing an E-Mail.

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Johannes Sixt]

Am 10.10.18 um 07:43 schrieb Junio C Hamano:
> We haven't seen much complaints and breakages reported against the
> two big "rewrite in C" topics around "rebase"; perhaps it is a good
> time to merge them to 'next' soonish to cook them for a few weeks
> before moving them to 'master'?

Please let me express my sincerest gratitude to Alban, Joel, 
Paul-Sebastian, Pratik, and Dscho. It is such a pleasure to work with 
the builtin rebase and stash commands on Windows now. I am using them 
since a month or two, and they work extremely well for me.

Thank you all for your hard work!

-- Hannes

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> writes:

> Am 10.10.18 um 07:43 schrieb Junio C Hamano:
>> We haven't seen much complaints and breakages reported against the
>> two big "rewrite in C" topics around "rebase"; perhaps it is a good
>> time to merge them to 'next' soonish to cook them for a few weeks
>> before moving them to 'master'?
>
> Please let me express my sincerest gratitude to Alban, Joel,
> Paul-Sebastian, Pratik, and Dscho. It is such a pleasure to work with
> the builtin rebase and stash commands on Windows now. I am using them
> since a month or two, and they work extremely well for me.
>
> Thank you all for your hard work!

OK.  With another Ack from Dscho, I'd feel safe to merge the
"rebase" topics 'next' and start cooking.  "stash" seems to be
almost there but I think it deserves a chance for a final touch-up
before hitting 'next' (see another thread with Thomas).

Thanks.

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Derrick Stolee]

On 10/10/2018 1:43 AM, Junio C Hamano wrote:
>
> * ds/reachable-topo-order (2018-09-21) 7 commits
>   - revision.c: refactor basic topo-order logic
>   - revision.h: add whitespace in flag definitions
>   - commit/revisions: bookkeeping before refactoring
>   - revision.c: begin refactoring --topo-order logic
>   - test-reach: add rev-list tests
>   - test-reach: add run_three_modes method
>   - prio-queue: add 'peek' operation
>
>   The revision walker machinery learned to take advantage of the
>   commit generation numbers stored in the commit-graph file.
>
>   What's the status of this topic?
I've reached out for review, especially on the rather large patch 
"revision.c: refactor basic topo-order logic" but have received no 
messages about it. I don't think anyone has even done a cursory style 
review.

I really think that this is a valuable topic, and it would be nice to 
have in 2.20, but I'm not pushing to merge something that no one has 
reviewed.

> * ds/format-commit-graph-docs (2018-08-21) 2 commits
>   - commit-graph.txt: improve formatting for asciidoc
>   - Docs: Add commit-graph tech docs to Makefile
>
>   Design docs for the commit-graph machinery is now made into HTML as
>   well as text.
>
>   Will discard.
>   I am inclined to drop these, as I do not see much clarity in HTML
>   output over the text source.  Opinions?
These have been marked for discard for a few weeks. I agree they should 
be discarded.

Thanks,
-Stolee

Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Duy Nguyen]

On Wed, Oct 10, 2018 at 7:43 AM Junio C Hamano <gitster@pobox.com> wrote:
> * nd/per-worktree-ref-iteration (2018-10-07) 9 commits
>  - SQUASH???
>  - reflog expire: cover reflog from all worktrees
>  - fsck: check HEAD and reflog from other worktrees
>  - fsck: Move fsck_head_link() to get_default_heads() to avoid some globals
>  - revision.c: better error reporting on ref from different worktrees
>  - revision.c: correct a parameter name
>  - refs: new ref types to make per-worktree refs visible to all worktrees
>  - Add a place for (not) sharing stuff between worktrees
>  - refs.c: indent with tabs, not spaces
>
>  What's the status of this topic?

There's one bug spotted by Eric and a few test cases to be added in
the reflog patch.
--
Duy