threads / discuss / 49522

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

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

## tl;dr

34 messages between Oct 10, 2018 and Oct 16, 2018.

replies: 33people: 12as markdown or json

Junio C Hamano· Oct 10, 2018, 05:43 UTC · lore

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.
Ævar Arnfjörð Bjarmason· Oct 10, 2018, 07:59 UTC · re: Junio C Hamano · lore

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

On Wed, Oct 10 2018, Junio C Hamano wrote:
Show 10 quoted lines
> * 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?
Jeff King· Oct 10, 2018, 15:06 UTC · re: Ævar Arnfjörð Bjarmason · lore

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

On Wed, Oct 10, 2018 at 09:59:16AM +0200, Ævar Arnfjörð Bjarmason wrote:
Show 19 quoted lines
> 
> 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
Johannes Schindelin· Oct 10, 2018, 12:57 UTC · re: Junio C Hamano · lore

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

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

Junio C Hamano· Oct 10, 2018, 13:19 UTC · re: Johannes Schindelin · lore

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

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:
Show 34 quoted lines
> 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
Junio C Hamano· Oct 11, 2018, 02:18 UTC · re: Johannes Schindelin · lore

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

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.

Johannes Schindelin· Oct 10, 2018, 13:04 UTC · re: Junio C Hamano · lore

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

Hi Junio,
On Wed, 10 Oct 2018, Junio C Hamano wrote:
Show 9 quoted lines
> * 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

Junio C Hamano· Oct 10, 2018, 13:13 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 18 quoted lines
> 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.
Phillip Wood· Oct 10, 2018, 13:58 UTC · re: Junio C Hamano · lore

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

On 10/10/2018 06:43, Junio C Hamano wrote:
Show 15 quoted lines
> 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
Junio C Hamano· Oct 11, 2018, 01:54 UTC · re: Phillip Wood · lore

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

Phillip Wood <phillip.wood@talktalk.net> writes:
Show 18 quoted lines
> 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.
Junio C Hamano· Oct 11, 2018, 22:40 UTC · re: Phillip Wood · lore

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

Phillip Wood <phillip.wood@talktalk.net> writes:
Show 18 quoted lines
> 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?

Stefan Beller· Oct 11, 2018, 22:59 UTC · re: Junio C Hamano · lore

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

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
Stefan Beller· Oct 11, 2018, 23:01 UTC · re: Stefan Beller · lore

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

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.
Junio C Hamano· Oct 12, 2018, 01:22 UTC · re: Stefan Beller · lore

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

Stefan Beller <sbeller@google.com> writes:
Show 17 quoted lines
> 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
Show 19 quoted lines
>
> (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);
>  	}
Stefan Beller· Oct 11, 2018, 23:06 UTC · re: Junio C Hamano · lore

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

On Thu, Oct 11, 2018 at 3:41 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 11 quoted lines
>  * 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)

Junio C Hamano· Oct 12, 2018, 00:51 UTC · re: Stefan Beller · lore

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

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.

Phillip Wood· Oct 12, 2018, 09:59 UTC · re: Junio C Hamano · lore

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

On 11/10/2018 23:40, Junio C Hamano wrote:
Show 35 quoted lines
> 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.

Show 17 quoted lines
>  * 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?
> 
> 
> 
Junio C Hamano· Oct 12, 2018, 13:36 UTC · re: Phillip Wood · lore

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

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.

Phillip Wood· Oct 16, 2018, 13:38 UTC · re: Junio C Hamano · lore

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

On 12/10/2018 14:36, Junio C Hamano wrote:
Show 10 quoted lines
> 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
Stefan Beller· Oct 16, 2018, 17:13 UTC · re: Phillip Wood · lore

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

On Tue, Oct 16, 2018 at 6:39 AM Phillip Wood <phillip.wood@talktalk.net> wrote:
Show 7 quoted lines
> > 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

Thomas Gummerer· Oct 10, 2018, 14:18 UTC · re: Junio C Hamano · lore

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

On 10/10, Junio C Hamano wrote:
Show 30 quoted lines
> * 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>

Junio C Hamano· Oct 11, 2018, 01:40 UTC · re: Thomas Gummerer · lore

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

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.
Show 6 quoted lines
> 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>
Michael Witten· Oct 10, 2018, 18:53 UTC · re: Junio C Hamano · lore

`--rebase-merges' still failing badly

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
Junio C Hamano· Oct 10, 2018, 23:01 UTC · re: Michael Witten · lore

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

Michael Witten <mfwitten@gmail.com> writes:
Show 10 quoted lines
> 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'.

Michael Witten· Oct 11, 2018, 02:48 UTC · re: Junio C Hamano · lore

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

On Thu, 11 Oct 2018 08:01:40 +0900, Junio wrote:
Show 32 quoted lines
> 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

Johannes Schindelin· Oct 12, 2018, 09:11 UTC · re: Michael Witten · lore

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

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.

Show 12 quoted lines
>     * 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.

Show 6 quoted lines
> 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

Show 136 quoted lines
> 
> 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
> 
Stefan Beller· Oct 10, 2018, 18:55 UTC · re: Junio C Hamano · lore

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

Show 10 quoted lines
> * 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/
Show 7 quoted lines
> * 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.

Show 6 quoted lines
> * 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.
Show 11 quoted lines
> * 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.
Show 7 quoted lines
>
> * 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.
Show 16 quoted lines
> * 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.
Show 15 quoted lines
> * 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
Junio C Hamano· Oct 11, 2018, 02:00 UTC · re: Stefan Beller · lore

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

Stefan Beller <sbeller@google.com> writes:
>> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
> I would suggest merging to 'next'.
OK.
Show 9 quoted lines
>> * 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.
Tim Schumacher· Oct 10, 2018, 20:38 UTC · re: Junio C Hamano · lore

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

On 10.10.18 07:43, Junio C Hamano wrote:
Show 10 quoted lines
> * 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.
Johannes Sixt· Oct 10, 2018, 21:25 UTC · re: Junio C Hamano · lore

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

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
Junio C Hamano· Oct 11, 2018, 01:53 UTC · re: Johannes Sixt · lore

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

Johannes Sixt <j6t@kdbg.org> writes:
Show 12 quoted lines
> 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.
Derrick Stolee· Oct 11, 2018, 11:16 UTC · re: Junio C Hamano · lore

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

On 10/10/2018 1:43 AM, Junio C Hamano wrote:
Show 14 quoted lines
>
> * 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.

Show 10 quoted lines
> * 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

Duy Nguyen· Oct 14, 2018, 12:21 UTC · re: Junio C Hamano · lore

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

On Wed, Oct 10, 2018 at 7:43 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> * 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

← back to recent threads