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

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. <[email protected]>

* 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. <[email protected]>

* 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. <[email protected]>

* 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. <[email protected]>

* 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. <[email protected]>

* 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. <[email protected]> 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. <[email protected]>

* 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. <[email protected]> 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. <[email protected]> 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.

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/[email protected]/

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

Hi Junio,

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

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.

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

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

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

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

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.

Hi Junio,

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

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.

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

Best Wishes

Phillip

Thanks.

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?

---

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(-)

index 145cfbae59..bdf4535d69 100644
@@ -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

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.

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)

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.

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.

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())

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

Thanks for taking a look!
Stefan

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*]: <[email protected]> [*2*]: <[email protected]>

;-) 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.

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.

[*3*] <[email protected]>

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

That should be:

merge - # Same as `merge r1'

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

* 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

Hi Michael,

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.

Sure, let's improve them.

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.

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.

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.

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.

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

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

Per [1] ("The whole series is

I would suggest merging to 'next'.

[1] https://public-inbox.org/git/CAGZ79kbamUK=d+-ejy9vopDiVZF7OVOngz1Zx9y04VR3HnmoXg@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/[email protected]/

You suggested to embrace it further and use caps for the parameter names in the docs comment.
https://public-inbox.org/git/[email protected]/

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.

Will resend.

Thanks.

Yeah I think discarding this is the right move.

is fixed in
https://public-inbox.org/git/[email protected]/

That is fixed locally

That has been addressed via
https://public-inbox.org/git/[email protected]/

Will resend after a local review.

Yes, please merge to next.

Stefan

OK.

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.

OK.

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

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.

Am 10.10.18 um 07:43 schrieb Junio C Hamano:

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

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.

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.

These have been marked for discard for a few weeks. I agree they should be discarded.

Thanks,
-Stolee

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