* What's cooking in git.git (Oct 2018, #01; Wed, 10)
@ 2018-10-10 5:43 Junio C Hamano
2018-10-10 7:59 ` Ævar Arnfjörð Bjarmason
` (10 more replies)
0 siblings, 11 replies; 34+ messages in thread
From: Junio C Hamano @ 2018-10-10 5:43 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 5:43 What's cooking in git.git (Oct 2018, #01; Wed, 10) Junio C Hamano
@ 2018-10-10 7:59 ` Ævar Arnfjörð Bjarmason
2018-10-10 15:06 ` Jeff King
2018-10-10 12:57 ` builtin stash/rebase, was " Johannes Schindelin
` (9 subsequent siblings)
10 siblings, 1 reply; 34+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-10-10 7:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
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?
^ permalink raw reply [flat|nested] 34+ messages in thread
* builtin stash/rebase, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 5:43 What's cooking in git.git (Oct 2018, #01; Wed, 10) Junio C Hamano
2018-10-10 7:59 ` Ævar Arnfjörð Bjarmason
@ 2018-10-10 12:57 ` Johannes Schindelin
2018-10-10 13:19 ` Junio C Hamano
2018-10-11 2:18 ` Junio C Hamano
2018-10-10 13:04 ` js/mingw-wants-vista-or-above, " Johannes Schindelin
` (8 subsequent siblings)
10 siblings, 2 replies; 34+ messages in thread
From: Johannes Schindelin @ 2018-10-10 12:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* js/mingw-wants-vista-or-above, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 5:43 What's cooking in git.git (Oct 2018, #01; Wed, 10) Junio C Hamano
2018-10-10 7:59 ` Ævar Arnfjörð Bjarmason
2018-10-10 12:57 ` builtin stash/rebase, was " Johannes Schindelin
@ 2018-10-10 13:04 ` Johannes Schindelin
2018-10-10 13:13 ` Junio C Hamano
2018-10-10 13:58 ` Phillip Wood
` (7 subsequent siblings)
10 siblings, 1 reply; 34+ messages in thread
From: Johannes Schindelin @ 2018-10-10 13:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
On Wed, 10 Oct 2018, Junio C Hamano wrote:
> * js/mingw-wants-vista-or-above (2018-10-04) 3 commits
> - mingw: bump the minimum Windows version to Vista
> - mingw: set _WIN32_WINNT explicitly for Git for Windows
> - compat/poll: prepare for targeting Windows Vista
>
> The minimum version of Windows supported by Windows port fo Git is
> now set to Vista.
>
> Will merge to 'next'.
Could I ask you to fast-track this to `master`? The code in `master`
unfortunately no longer compiles in a current Git for Windows SDK, meaning
that all of our Continuous Testing fails as long as these patches are not
merged.
I do not see how this could affect non-Windows builds, so everybody else
should be unaffected anyway.
Thanks,
Dscho
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: js/mingw-wants-vista-or-above, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 13:04 ` js/mingw-wants-vista-or-above, " Johannes Schindelin
@ 2018-10-10 13:13 ` Junio C Hamano
0 siblings, 0 replies; 34+ messages in thread
From: Junio C Hamano @ 2018-10-10 13:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Junio,
>
> On Wed, 10 Oct 2018, Junio C Hamano wrote:
>
>> * js/mingw-wants-vista-or-above (2018-10-04) 3 commits
>> - mingw: bump the minimum Windows version to Vista
>> - mingw: set _WIN32_WINNT explicitly for Git for Windows
>> - compat/poll: prepare for targeting Windows Vista
>>
>> The minimum version of Windows supported by Windows port fo Git is
>> now set to Vista.
>>
>> Will merge to 'next'.
>
> Could I ask you to fast-track this to `master`? The code in `master`
> unfortunately no longer compiles in a current Git for Windows SDK, meaning
> that all of our Continuous Testing fails as long as these patches are not
> merged.
Absolutely. There is no point keeping it in 'pu', as nobody would
touch it in my tree until it hits 'next' and probably 'master' and
the change would get wider exposure to folks to whom it matters in
your tree anyway.
Thanks for pinging.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: builtin stash/rebase, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 12:57 ` builtin stash/rebase, was " Johannes Schindelin
@ 2018-10-10 13:19 ` Junio C Hamano
2018-10-11 2:18 ` Junio C Hamano
1 sibling, 0 replies; 34+ messages in thread
From: Junio C Hamano @ 2018-10-10 13:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Speaking about the two `rebase` ones: they are simple fixup! commits,
> could I trouble you to fetch and cherry-pick them into `pu`, or would you
> prefer if I sent another iteration of `rebase-in-c-4-opts`?
If it were only about me, then the former if I can do my own pace is
easier. If you promise that you won't complain if a few commits
lose the amlog notes by accident when such tree mangling is done,
that would be even better, but I'd be careful anyway.
I'd rather limit number of changes not seen on the list that come
into my tree, so it is likely that I'd parrot these fixup commits or
result of "commit --amend" to the list if we take that route.
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Junio,
>
> On Wed, 10 Oct 2018, Junio C Hamano wrote:
>
>> We haven't seen much complaints and breakages reported against the
>> two big "rewrite in C" topics around "rebase"; perhaps it is a good
>> time to merge them to 'next' soonish to cook them for a few weeks
>> before moving them to 'master'?
>
> I would be in favor, as long as the fixup patches I have in Git for
> Windows made it in:
>
> https://github.com/git-for-windows/git/commit/6bc7024aecdb1aeb2760c519f7b26e6e5ef21051
> fixup! builtin rebase: support `-C` and `--whitespace=<type>`
>
> https://github.com/git-for-windows/git/commit/1e6a1c510ffeae5bb0a4bda7f0528a8213728837
> fixup! builtin rebase: support `--gpg-sign` option
>
> https://github.com/git-for-windows/git/commit/ddb6e5ca19d5cdd318bc4bcbb7f7f3fb0892c8cc
> fixup! rebase -i: implement the main part of interactive rebase as a builtin
>
> https://github.com/git-for-windows/git/commit/2af24038a95a3879aa0c29d91a43180b9465247e
> fixup! stash: convert apply to builtin
>
> It seems that Alban picked up the `rebase -i` one, but the other three
> have not made it into `pu` yet (the two `rebase` ones are really my fault,
> I did not yet find time).
>
> Speaking about the two `rebase` ones: they are simple fixup! commits,
> could I trouble you to fetch and cherry-pick them into `pu`, or would you
> prefer if I sent another iteration of `rebase-in-c-4-opts`?
>
> Ciao,
> Dscho
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 5:43 What's cooking in git.git (Oct 2018, #01; Wed, 10) Junio C Hamano
` (2 preceding siblings ...)
2018-10-10 13:04 ` js/mingw-wants-vista-or-above, " Johannes Schindelin
@ 2018-10-10 13:58 ` Phillip Wood
2018-10-11 1:54 ` Junio C Hamano
2018-10-11 22:40 ` Junio C Hamano
2018-10-10 14:18 ` Thomas Gummerer
` (6 subsequent siblings)
10 siblings, 2 replies; 34+ messages in thread
From: Phillip Wood @ 2018-10-10 13:58 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Stefan Beller
On 10/10/2018 06:43, Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'. The ones marked with '.' do not appear in any of
> the integration branches, but I am still holding onto them.
>
> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
> - diff --color-moved: fix a memory leak
> - diff --color-moved-ws: fix another memory leak
> - diff --color-moved-ws: fix a memory leak
> - diff --color-moved-ws: fix out of bounds string access
> - diff --color-moved-ws: fix double free crash
>
> Various fixes to "diff --color-moved-ws".
>
> What's the status of this topic?
I think it is ready for next - Stefan was happy with the last iteration.
Best Wishes
Phillip
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 5:43 What's cooking in git.git (Oct 2018, #01; Wed, 10) Junio C Hamano
` (3 preceding siblings ...)
2018-10-10 13:58 ` Phillip Wood
@ 2018-10-10 14:18 ` Thomas Gummerer
2018-10-11 1:40 ` Junio C Hamano
2018-10-10 18:51 ` `--rebase-merges' still failing badly Michael Witten
` (5 subsequent siblings)
10 siblings, 1 reply; 34+ messages in thread
From: Thomas Gummerer @ 2018-10-10 14:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Paul-Sebastian Ungureanu
On 10/10, Junio C Hamano wrote:
> * ps/stash-in-c (2018-08-31) 20 commits
> - stash: replace all `write-tree` child processes with API calls
> - stash: optimize `get_untracked_files()` and `check_changes()`
> - stash: convert `stash--helper.c` into `stash.c`
> - stash: convert save to builtin
> - stash: make push -q quiet
> - stash: convert push to builtin
> - stash: convert create to builtin
> - stash: convert store to builtin
> - stash: mention options in `show` synopsis
> - stash: convert show to builtin
> - stash: convert list to builtin
> - stash: convert pop to builtin
> - stash: convert branch to builtin
> - stash: convert drop and clear to builtin
> - stash: convert apply to builtin
> - stash: add tests for `git stash show` config
> - stash: rename test cases to be more descriptive
> - stash: update test cases conform to coding guidelines
> - stash: improve option parsing test coverage
> - sha1-name.c: add `get_oidf()` which acts like `get_oid()`
>
> "git stash" rewritten in C.
>
> Undecided. This also has been part of my personal build. I do not
> offhand recall if this also had the same exposure to the end users
> as "rebase" and "rebase -i". I am tempted to merge this to 'next'
> soonish.
>
> Opinions?
There was a v9 of this series [*1*], which hasn't been picked up yet.
Was that intentional, or an oversight?
I left some comments on that iteration. Some were just style nits,
but I think at least [*2*] should be addressed before we merge this
down to master, not sure if any of my other comments apply to v8 as
well. I'm happy to send fixup patches, or a patches on top of
this series for that and my other comments, should they apply to v8,
or wait for Paul-Sebastian to send a re-roll. What do you prefer?
[*1*]: <cover.1537913094.git.ungureanupaulsebastian@gmail.com>
[*2*]: <20180930174848.GE2253@hank.intra.tgummerer.com>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 7:59 ` Ævar Arnfjörð Bjarmason
@ 2018-10-10 15:06 ` Jeff King
0 siblings, 0 replies; 34+ messages in thread
From: Jeff King @ 2018-10-10 15:06 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, git
On Wed, Oct 10, 2018 at 09:59:16AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Oct 10 2018, Junio C Hamano wrote:
>
> > * jk/drop-ancient-curl (2017-08-09) 5 commits
> > - http: #error on too-old curl
> > - curl: remove ifdef'd code never used with curl >=7.19.4
> > - http: drop support for curl < 7.19.4
> > - http: drop support for curl < 7.16.0
> > - http: drop support for curl < 7.11.1
> >
> > Some code in http.c that has bitrot is being removed.
> >
> > Expecting a reroll.
>
> There's been no activity on this for 6 months since I sent a "hey what's
> going on with it" E-Mail in:
> https://public-inbox.org/git/20180404204920.GA15402@sigill.intra.peff.net/
>
> Maybe it should just be dropped?
That's fine with me. I think it was a nice cleanup as long as nobody
cared, but some people did seem to care. Maybe they care less now that
more time has passed, but it just hasn't really been worth the time to
revisit.
I'm OK to drop it; the patches are on the list if we want to look at it
again later.
-Peff
^ permalink raw reply [flat|nested] 34+ messages in thread
* `--rebase-merges' still failing badly
2018-10-10 5:43 What's cooking in git.git (Oct 2018, #01; Wed, 10) Junio C Hamano
` (4 preceding siblings ...)
2018-10-10 14:18 ` Thomas Gummerer
@ 2018-10-10 18:51 ` Michael Witten
2018-10-10 19:00 ` Michael Witten
` (2 more replies)
2018-10-10 18:55 ` What's cooking in git.git (Oct 2018, #01; Wed, 10) Stefan Beller
` (4 subsequent siblings)
10 siblings, 3 replies; 34+ messages in thread
From: Michael Witten @ 2018-10-10 18:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Brian M. Carlson, Pratik Karki, git
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 5:43 What's cooking in git.git (Oct 2018, #01; Wed, 10) Junio C Hamano
` (5 preceding siblings ...)
2018-10-10 18:51 ` `--rebase-merges' still failing badly Michael Witten
@ 2018-10-10 18:55 ` Stefan Beller
2018-10-11 2:00 ` Junio C Hamano
2018-10-10 20:38 ` Tim Schumacher
` (3 subsequent siblings)
10 siblings, 1 reply; 34+ messages in thread
From: Stefan Beller @ 2018-10-10 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
> - diff --color-moved: fix a memory leak
> - diff --color-moved-ws: fix another memory leak
> - diff --color-moved-ws: fix a memory leak
> - diff --color-moved-ws: fix out of bounds string access
> - diff --color-moved-ws: fix double free crash
>
> Various fixes to "diff --color-moved-ws".
>
> What's the status of this topic?
Per [1] ("The whole series is
Reviewed-by: Stefan Beller <sbeller@google.com>"),
I would suggest merging to 'next'.
[1] https://public-inbox.org/git/CAGZ79kbamUK=d+-ejy9vopDiVZF7OVOngz1Zx9y04VR3HnmoXg@mail.gmail.com/
> * sb/strbuf-h-update (2018-09-29) 1 commit
> - strbuf.h: format according to coding guidelines
>
> Code clean-up to serve as a BCP example.
>
> What's the status of this one after the discussion thread stopped here?
> cf. <CAGZ79kbV6QjsFKcD2uG_P9j1AvzSNQSi-_jXGQ9w0YU9fjhEGg@mail.gmail.com>
I was waiting for more discussion and stricter guidelines,
which never happened.
The only controversial issue about this patch is whether we want
to name all parameters or only when we feel like it.
Peff did not seem to care about this particular detail
https://public-inbox.org/git/20180929073827.GD2174@sigill.intra.peff.net/
You suggested to embrace it further and use caps for the parameter
names in the docs comment.
https://public-inbox.org/git/xmqq8t3lb8uu.fsf@gitster-ct.c.googlers.com/
The patch as-is just adds names everywhere.
I'd be happy to resend with either
(a) not enforcing names everywhere, but only as needed or
(b) having names everywhere, capitalizing them NAMES in
the doc comment.
I am tempted to ask for
(c) take as-is, defer the rewording of doc strings for a follow up patch.
> * sb/grep-submodule-cleanup (2018-10-10) 1 commit
> - builtin/grep.c: remove superfluous submodule code
>
> Code clean-up.
>
> cf. <20181010001037.74709-1-jonathantanmy@google.com>
Will resend.
> * bw/submodule-name-to-dir (2018-08-10) 2 commits
> - submodule: munge paths to submodule git directories
> - submodule: create helper to build paths to submodule gitdirs
>
> In modern repository layout, the real body of a cloned submodule
> repository is held in .git/modules/ of the superproject, indexed by
> the submodule name. URLencode the submodule name before computing
> the name of the directory to make sure they form a flat namespace.
>
> Kicked back to 'pu', expecting further work on the topic.
> cf. <CAGZ79kYnbjaPoWdda0SM_-_X77mVyYC7JO61OV8nm2yj3Q1OvQ@mail.gmail.com>
Thanks.
>
> * sb/submodule-move-head-with-corruption (2018-08-28) 2 commits
> - submodule.c: warn about missing submodule git directories
> - t2013: add test for missing but active submodule
>
> Will discard and wait for a cleaned-up rewrite.
> cf. <20180907195349.GA103699@aiede.svl.corp.google.com>
Yeah I think discarding this is the right move.
> * sb/submodule-recursive-fetch-gets-the-tip (2018-09-12) 9 commits
> - builtin/fetch: check for submodule updates for non branch fetches
> - fetch: retry fetching submodules if sha1 were not fetched
> - submodule: fetch in submodules git directory instead of in worktree
> - submodule.c: do not copy around submodule list
> - submodule: move global changed_submodule_names into fetch submodule struct
> - submodule.c: sort changed_submodule_names before searching it
> - submodule.c: fix indentation
> - sha1-array: provide oid_array_filter
> - string-list: add string_list_{pop, last} functions
>
> "git fetch --recurse-submodules" may not fetch the necessary commit
> that is bound to the superproject, which is getting corrected.
>
> Expecting a reroll.
> cf. <b16af8c0-0435-0de4-ed6c-53888d6190af@ramsayjones.plus.com>
is fixed in
https://public-inbox.org/git/20180917213559.126404-7-sbeller@google.com/
> cf. <CAGZ79kbavjVbTqXsmtjW6=jhkq47_p3mc6=92xOp4_mfhqDtvw@mail.gmail.com>
That is fixed locally
> cf. <CAGZ79kZKKf9N8yx9EuCRZhrZS_mA2218PouEG7aHDhK2bJGEdA@mail.gmail.com>
That has been addressed via
https://public-inbox.org/git/20180925194755.105578-1-sbeller@google.com/
Will resend after a local review.
> * pk/rebase-in-c-6-final (2018-10-09) 1 commit
> - rebase: default to using the builtin rebase
> (this branch uses ag/rebase-i-in-c, js/rebase-in-c-5.5-work-with-rebase-i-in-c, pk/rebase-in-c, pk/rebase-in-c-2-basic, pk/rebase-in-c-3-acts, pk/rebase-in-c-4-opts and pk/rebase-in-c-5-test; is tangled with ag/sequencer-reduce-rewriting-todo, jc/rebase-in-c-5-test-typofix and js/rebase-i-break.)
>
> The final step of rewriting "rebase -i" in C.
>
> Undecided.
> I've been using this (i.e. the whole "rebase -i" and "rebase"
> rewritten in C) in my personal build, and I also know users on
> Windows port have been using it with the last feature release. I
> am tempted to merge the whole thing to 'next' soonish.
>
> Opinions? It's the last chance to remove any existing and avoid
> any future "oops, that was wrong, and here is a fix-up"
> embarrassment in these topics.
Yes, please merge to next.
Stefan
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: `--rebase-merges' still failing badly
2018-10-10 18:51 ` `--rebase-merges' still failing badly Michael Witten
@ 2018-10-10 19:00 ` Michael Witten
2018-10-10 23:01 ` Junio C Hamano
2018-10-12 9:11 ` Johannes Schindelin
2 siblings, 0 replies; 34+ messages in thread
From: Michael Witten @ 2018-10-10 19:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Brian M. Carlson, Pratik Karki, git
On Wed, 10 Oct 2018 18:51:17 -0000, Michael Witten wrote:
> merge - # Same as merge -C abcde r1
That should be:
merge - # Same as `merge r1'
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 5:43 What's cooking in git.git (Oct 2018, #01; Wed, 10) Junio C Hamano
` (6 preceding siblings ...)
2018-10-10 18:55 ` What's cooking in git.git (Oct 2018, #01; Wed, 10) Stefan Beller
@ 2018-10-10 20:38 ` Tim Schumacher
2018-10-10 21:25 ` Johannes Sixt
` (2 subsequent siblings)
10 siblings, 0 replies; 34+ messages in thread
From: Tim Schumacher @ 2018-10-10 20:38 UTC (permalink / raw)
To: Junio C Hamano, git
On 10.10.18 07:43, Junio C Hamano wrote:
> * ts/alias-of-alias (2018-09-17) 3 commits
> (merged to 'next' on 2018-10-09 at ac19b4730b)
> + t0014: introduce an alias testing suite
> + alias: show the call history when an alias is looping
> + alias: add support for aliases of an alias
>
> An alias that expands to another alias has so far been forbidden,
> but now it is allowed to create such an alias.
>
> Will merge to 'master'.
Oh well, I still have the changed comment stored locally.
I guess that has to wait for another time.
Anyways, thanks for pulling this in.
PS: I hope that this E-Mail is formatted correctly. Thunderbird
received an update and now it doesn't show me plain text when
composing an E-Mail.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 5:43 What's cooking in git.git (Oct 2018, #01; Wed, 10) Junio C Hamano
` (7 preceding siblings ...)
2018-10-10 20:38 ` Tim Schumacher
@ 2018-10-10 21:25 ` Johannes Sixt
2018-10-11 1:53 ` Junio C Hamano
2018-10-11 11:16 ` Derrick Stolee
2018-10-14 12:21 ` Duy Nguyen
10 siblings, 1 reply; 34+ messages in thread
From: Johannes Sixt @ 2018-10-10 21:25 UTC (permalink / raw)
To: Alban Gruin, Joel Teichroeb, Paul-Sebastian Ungureanu,
Pratik Karki, Johannes Schindelin
Cc: Junio C Hamano, git
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: `--rebase-merges' still failing badly
2018-10-10 18:51 ` `--rebase-merges' still failing badly Michael Witten
2018-10-10 19:00 ` Michael Witten
@ 2018-10-10 23:01 ` Junio C Hamano
2018-10-11 2:44 ` Michael Witten
2018-10-12 9:11 ` Johannes Schindelin
2 siblings, 1 reply; 34+ messages in thread
From: Junio C Hamano @ 2018-10-10 23:01 UTC (permalink / raw)
To: Michael Witten; +Cc: Johannes Schindelin, Brian M. Carlson, Pratik Karki, git
Michael Witten <mfwitten@gmail.com> writes:
> On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote:
>
>> We haven't seen much complaints and breakages reported against the
>> two big "rewrite in C" topics around "rebase"; perhaps it is a good
>> time to merge them to 'next' soonish to cook them for a few weeks
>> before moving them to 'master'?
>
> In my opinion, the `--rebase-merges' feature has been broken since the
> beginning, and the builtin version should be fixed before it is moved
> ahead.
I'll omit the remainder of the message not because I disagree with
your suggested improvements to "rebase-merges" (that conversation
should happen primarily with Dscho), but because I need to react to
the above three lines.
If "rebase-merges" has been broken since the beginning, as long as
the "rewrite in C" topics around "rebase" do not make it even worse,
I do not think it is a good move to block the topics moving forward.
If the feature were so broken that it is not practically useful,
then people wouldn't be using it in the versions of Git before the
rewrite, so it won't harm anybody if the same feature in the rewritten
version is equally (or even more severely) broken, as long as the
other parts of the feature works at least equally well compared to
the older version.
We are not in the business of hostage taking.
What *should* block the rewrited version is a regression,
i.e. something that used to work well no longer works or works
differently in such a way that established workflows need to be
adjusted.
In any case, suggestions to improve "rebase-merges" is a very much
welcome thing to be discussed on the list, so thanks for raising the
issue. What I wanted to say is that I do not think that is a reason
to keep "rewrite in C" waiting in 'pu'.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 14:18 ` Thomas Gummerer
@ 2018-10-11 1:40 ` Junio C Hamano
0 siblings, 0 replies; 34+ messages in thread
From: Junio C Hamano @ 2018-10-11 1:40 UTC (permalink / raw)
To: Thomas Gummerer; +Cc: git, Paul-Sebastian Ungureanu
Thomas Gummerer <t.gummerer@gmail.com> writes:
> There was a v9 of this series [*1*], which hasn't been picked up yet.
> Was that intentional, or an oversight?
;-) Yes, I often miss patches that are buried in other discussions,
but this time, it was quite deliberate. I saw comments that pointed
out at least one thing that needs to be fixed before the series can
move forward, so I skipped that iteration, anticipating another
round of update.
Also, I was waiting for [*3*] to be answered.
> I left some comments on that iteration. Some were just style nits,
> but I think at least [*2*] should be addressed before we merge this
> down to master, not sure if any of my other comments apply to v8 as
> well. I'm happy to send fixup patches, or a patches on top of
> this series for that and my other comments, should they apply to v8,
> or wait for Paul-Sebastian to send a re-roll. What do you prefer?
The ideal from my point of view is to see responses to your comments
in the original thread (which is about 1300 messages ago in the list
archive by now) by Paul-Sebastian, possibly responded by you and/or
others, resulting in a concensus on what the right update for the
patches should be, finally followed by v10, which hopefully would be
the final one.
> [*1*]: <cover.1537913094.git.ungureanupaulsebastian@gmail.com>
> [*2*]: <20180930174848.GE2253@hank.intra.tgummerer.com>
[*3*] <xmqq8t3oksve.fsf@gitster-ct.c.googlers.com>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 21:25 ` Johannes Sixt
@ 2018-10-11 1:53 ` Junio C Hamano
0 siblings, 0 replies; 34+ messages in thread
From: Junio C Hamano @ 2018-10-11 1:53 UTC (permalink / raw)
To: Johannes Sixt
Cc: Alban Gruin, Joel Teichroeb, Paul-Sebastian Ungureanu,
Pratik Karki, Johannes Schindelin, git
Johannes Sixt <j6t@kdbg.org> writes:
> Am 10.10.18 um 07:43 schrieb Junio C Hamano:
>> We haven't seen much complaints and breakages reported against the
>> two big "rewrite in C" topics around "rebase"; perhaps it is a good
>> time to merge them to 'next' soonish to cook them for a few weeks
>> before moving them to 'master'?
>
> Please let me express my sincerest gratitude to Alban, Joel,
> Paul-Sebastian, Pratik, and Dscho. It is such a pleasure to work with
> the builtin rebase and stash commands on Windows now. I am using them
> since a month or two, and they work extremely well for me.
>
> Thank you all for your hard work!
OK. With another Ack from Dscho, I'd feel safe to merge the
"rebase" topics 'next' and start cooking. "stash" seems to be
almost there but I think it deserves a chance for a final touch-up
before hitting 'next' (see another thread with Thomas).
Thanks.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 13:58 ` Phillip Wood
@ 2018-10-11 1:54 ` Junio C Hamano
2018-10-11 22:40 ` Junio C Hamano
1 sibling, 0 replies; 34+ messages in thread
From: Junio C Hamano @ 2018-10-11 1:54 UTC (permalink / raw)
To: Phillip Wood; +Cc: git, Stefan Beller
Phillip Wood <phillip.wood@talktalk.net> writes:
> On 10/10/2018 06:43, Junio C Hamano wrote:
>> Here are the topics that have been cooking. Commits prefixed with
>> '-' are only in 'pu' (proposed updates) while commits prefixed with
>> '+' are in 'next'. The ones marked with '.' do not appear in any of
>> the integration branches, but I am still holding onto them.
>>
>> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
>> - diff --color-moved: fix a memory leak
>> - diff --color-moved-ws: fix another memory leak
>> - diff --color-moved-ws: fix a memory leak
>> - diff --color-moved-ws: fix out of bounds string access
>> - diff --color-moved-ws: fix double free crash
>>
>> Various fixes to "diff --color-moved-ws".
>>
>> What's the status of this topic?
>
> I think it is ready for next - Stefan was happy with the last iteration.
Thanks.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 18:55 ` What's cooking in git.git (Oct 2018, #01; Wed, 10) Stefan Beller
@ 2018-10-11 2:00 ` Junio C Hamano
0 siblings, 0 replies; 34+ messages in thread
From: Junio C Hamano @ 2018-10-11 2:00 UTC (permalink / raw)
To: Stefan Beller; +Cc: git
Stefan Beller <sbeller@google.com> writes:
>> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
> I would suggest merging to 'next'.
OK.
>> * sb/strbuf-h-update (2018-09-29) 1 commit
> The patch as-is just adds names everywhere.
> I'd be happy to resend with either
> (a) not enforcing names everywhere, but only as needed or
> (b) having names everywhere, capitalizing them NAMES in
> the doc comment.
>
> I am tempted to ask for
> (c) take as-is, defer the rewording of doc strings for a follow up patch.
As long as the planned update eventually comes before all of us
forget, (c) is fine by me. I'll mark it to be merged to 'next' for
now, and follow through that plan, unless somebody else stops me
before it happens.
>> * sb/submodule-recursive-fetch-gets-the-tip (2018-09-12) 9 commits
> Will resend after a local review.
OK.
Thanks for helping me in updating the status for various topics.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: builtin stash/rebase, was Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 12:57 ` builtin stash/rebase, was " Johannes Schindelin
2018-10-10 13:19 ` Junio C Hamano
@ 2018-10-11 2:18 ` Junio C Hamano
1 sibling, 0 replies; 34+ messages in thread
From: Junio C Hamano @ 2018-10-11 2:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: `--rebase-merges' still failing badly
2018-10-10 23:01 ` Junio C Hamano
@ 2018-10-11 2:44 ` Michael Witten
0 siblings, 0 replies; 34+ messages in thread
From: Michael Witten @ 2018-10-11 2:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Brian M. Carlson, Pratik Karki, git
On Thu, 11 Oct 2018 08:01:40 +0900, Junio wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote:
>>
>>> We haven't seen much complaints and breakages reported against the
>>> two big "rewrite in C" topics around "rebase"; perhaps it is a good
>>> time to merge them to 'next' soonish to cook them for a few weeks
>>> before moving them to 'master'?
>>
>> In my opinion, the `--rebase-merges' feature has been broken since the
>> beginning, and the builtin version should be fixed before it is moved
>> ahead.
>
> [...]
>
> If "rebase-merges" has been broken since the beginning, as long as the
> "rewrite in C" topics around "rebase" do not make it even worse, I do
> not think it is a good move to block the topics moving forward. If the
> feature were so broken that it is not practically useful, then people
> wouldn't be using it in the versions of Git before the rewrite, so it
> won't harm anybody if the same feature in the rewritten version is
> equally (or even more severely) broken, as long as the other parts of
> the feature works at least equally well compared to the older version.
>
> We are not in the business of hostage taking.
>
> What *should* block the rewrited version is a regression, i.e.
> something that used to work well no longer works or works differently
> in such a way that established workflows need to be adjusted.
>
> [...] I do not think that is a reason to keep "rewrite in C" waiting in
> 'pu'.
* Your logic is appealing, and I nearly pursuaded myself by the same
reasoning to submit my email as a separate discussion, as you suggest.
However, what convinced me otherwise is the following:
The closer you move the rewrite to a fast-forward-only public
branch name, the more likely downstream projects are going to
set up new, long-lived releases around this very useful but
nevertheless broken feature.
The moment you announce a new release, there are going to be a bunch of
people who grab that release and then NEVER look back, and so the rest
of us will be stuck with this problem for who knows how long.
So, not only is this an appeal to the authors to fix this problem, but
its also an appeal to you to make sure that the next major release
includes the fix.
* Also, I say the following without irony or tongue in cheek:
Maybe, no one has complained because few people are using this
feature yet, or their commit summaries are simplistic, or they've
got workarounds (as I've got).
Not only must this feature be turned on explicitly, but `git' has
existed for over a decade *without* it; users who are interested in
sophisticated management of commit history have already developed other
ways to achieve the same result (I know I did), or their commit
messages are so simplistic that the bug is never triggered, or they
just plan around it by automatically running a quick search/replace for
the offending characters or for the irritating "labels".
If the last decade has shown us anything, it's that git's fundamentals
are so good that programmers can get around any bug on their own,
without having to appeal to others for help. And, what is a programmer
if not someone who is used to making things Just Work [Damnit]?
As an illustration, consider the recent `break' command that is being
added to the repertoire of `git rebase -i'. Hell, I (and probably many
others) have been doing that for YEARS with:
x false
No need for a "new" command. I bet that 10 years from now, people will
*still* be using their own ways, and will *still* be totally oblivious
to the existence of `break'.
That is to say, I wouldn't put much faith in the degree to which people
report issues. The programming world has a lot of itchy backs, and just
as many personal inventions for scratching them.
As always, thanks for taking the time to review everyone's input.
Sincerely,
Michael Witten
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 5:43 What's cooking in git.git (Oct 2018, #01; Wed, 10) Junio C Hamano
` (8 preceding siblings ...)
2018-10-10 21:25 ` Johannes Sixt
@ 2018-10-11 11:16 ` Derrick Stolee
2018-10-14 12:21 ` Duy Nguyen
10 siblings, 0 replies; 34+ messages in thread
From: Derrick Stolee @ 2018-10-11 11:16 UTC (permalink / raw)
To: Junio C Hamano, GIT Mailing-list
On 10/10/2018 1:43 AM, Junio C Hamano wrote:
>
> * ds/reachable-topo-order (2018-09-21) 7 commits
> - revision.c: refactor basic topo-order logic
> - revision.h: add whitespace in flag definitions
> - commit/revisions: bookkeeping before refactoring
> - revision.c: begin refactoring --topo-order logic
> - test-reach: add rev-list tests
> - test-reach: add run_three_modes method
> - prio-queue: add 'peek' operation
>
> The revision walker machinery learned to take advantage of the
> commit generation numbers stored in the commit-graph file.
>
> What's the status of this topic?
I've reached out for review, especially on the rather large patch
"revision.c: refactor basic topo-order logic" but have received no
messages about it. I don't think anyone has even done a cursory style
review.
I really think that this is a valuable topic, and it would be nice to
have in 2.20, but I'm not pushing to merge something that no one has
reviewed.
> * ds/format-commit-graph-docs (2018-08-21) 2 commits
> - commit-graph.txt: improve formatting for asciidoc
> - Docs: Add commit-graph tech docs to Makefile
>
> Design docs for the commit-graph machinery is now made into HTML as
> well as text.
>
> Will discard.
> I am inclined to drop these, as I do not see much clarity in HTML
> output over the text source. Opinions?
These have been marked for discard for a few weeks. I agree they should
be discarded.
Thanks,
-Stolee
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 13:58 ` Phillip Wood
2018-10-11 1:54 ` Junio C Hamano
@ 2018-10-11 22:40 ` Junio C Hamano
2018-10-11 22:59 ` [PATCH] diff.c: die on unknown color-moved ws mode Stefan Beller
` (2 more replies)
1 sibling, 3 replies; 34+ messages in thread
From: Junio C Hamano @ 2018-10-11 22:40 UTC (permalink / raw)
To: Phillip Wood; +Cc: git, Stefan Beller
Phillip Wood <phillip.wood@talktalk.net> writes:
> On 10/10/2018 06:43, Junio C Hamano wrote:
>> Here are the topics that have been cooking. Commits prefixed with
>> '-' are only in 'pu' (proposed updates) while commits prefixed with
>> '+' are in 'next'. The ones marked with '.' do not appear in any of
>> the integration branches, but I am still holding onto them.
>>
>> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
>> - diff --color-moved: fix a memory leak
>> - diff --color-moved-ws: fix another memory leak
>> - diff --color-moved-ws: fix a memory leak
>> - diff --color-moved-ws: fix out of bounds string access
>> - diff --color-moved-ws: fix double free crash
>>
>> Various fixes to "diff --color-moved-ws".
>>
>> What's the status of this topic?
>
> I think it is ready for next - Stefan was happy with the last iteration.
This is not about your fixes, but I was skimming the color-moved
support in general as a final sanity check to move this forward and
noticed that
$ git diff --color-moved-ws=ignore-any master...
does not do anything interesting, which is broken at at least two
points.
* There is no "ignore-any" supported by the feature---I think that
the parser for the option should have noticed and barfed, but it
did not. It merely emitted a message to the standard output and
let it scroll away with the huge diff before the reader noticed
it.
* After fixing ignore-any to one of the supported option
(e.g. "ignore-all-spaces"), the color-moved feature still did not
trigger. I think the presence of --color-moved-ws by itself is a
hint that the user wants --color-moved to be used. If it turns
out that there are some valid use cases where --color-moved-ws
may have to be set but the color-moved feature should not be
enabled, then
diff --color-moved-ws=ignore-all-space --no-color-moved
can be used to countermand this, of course.
Am I missing something or are these mere small sloppiness in the
current code?
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH] diff.c: die on unknown color-moved ws mode
2018-10-11 22:40 ` Junio C Hamano
@ 2018-10-11 22:59 ` Stefan Beller
2018-10-11 23:01 ` Stefan Beller
2018-10-12 1:22 ` Junio C Hamano
2018-10-11 23:06 ` What's cooking in git.git (Oct 2018, #01; Wed, 10) Stefan Beller
2018-10-12 9:59 ` Phillip Wood
2 siblings, 2 replies; 34+ messages in thread
From: Stefan Beller @ 2018-10-11 22:59 UTC (permalink / raw)
To: gitster; +Cc: git, phillip.wood, sbeller
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
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH] diff.c: die on unknown color-moved ws mode
2018-10-11 22:59 ` [PATCH] diff.c: die on unknown color-moved ws mode Stefan Beller
@ 2018-10-11 23:01 ` Stefan Beller
2018-10-12 1:22 ` Junio C Hamano
1 sibling, 0 replies; 34+ messages in thread
From: Stefan Beller @ 2018-10-11 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, phillip.wood
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-11 22:40 ` Junio C Hamano
2018-10-11 22:59 ` [PATCH] diff.c: die on unknown color-moved ws mode Stefan Beller
@ 2018-10-11 23:06 ` Stefan Beller
2018-10-12 0:51 ` Junio C Hamano
2018-10-12 9:59 ` Phillip Wood
2 siblings, 1 reply; 34+ messages in thread
From: Stefan Beller @ 2018-10-11 23:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: phillip.wood, git
On Thu, Oct 11, 2018 at 3:41 PM Junio C Hamano <gitster@pobox.com> wrote:
> * After fixing ignore-any to one of the supported option
> (e.g. "ignore-all-spaces"), the color-moved feature still did not
> trigger. I think the presence of --color-moved-ws by itself is a
> hint that the user wants --color-moved to be used. If it turns
> out that there are some valid use cases where --color-moved-ws
> may have to be set but the color-moved feature should not be
> enabled, then
>
> diff --color-moved-ws=ignore-all-space --no-color-moved
>
> can be used to countermand this, of course.
I had the same idea for --color-moved to imply --color, but there
we had some issues with configured settings, as we do not want
diff.colorMoved to imply colored patches, but only when given on
the command line.
I think we should add these tweaks, such that
color-moved-ws implies color-moved (both config and CLI options)
and --color-moved implies --color (command line only)
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-11 23:06 ` What's cooking in git.git (Oct 2018, #01; Wed, 10) Stefan Beller
@ 2018-10-12 0:51 ` Junio C Hamano
0 siblings, 0 replies; 34+ messages in thread
From: Junio C Hamano @ 2018-10-12 0:51 UTC (permalink / raw)
To: Stefan Beller; +Cc: phillip.wood, git
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] diff.c: die on unknown color-moved ws mode
2018-10-11 22:59 ` [PATCH] diff.c: die on unknown color-moved ws mode Stefan Beller
2018-10-11 23:01 ` Stefan Beller
@ 2018-10-12 1:22 ` Junio C Hamano
1 sibling, 0 replies; 34+ messages in thread
From: Junio C Hamano @ 2018-10-12 1:22 UTC (permalink / raw)
To: Stefan Beller; +Cc: git, phillip.wood
Stefan Beller <sbeller@google.com> writes:
> Noticed-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>
>
> There is no "ignore-any" supported by the feature---I think that
> the parser for the option should have noticed and barfed, but it
> did not. It merely emitted a message to the standard output and
> let it scroll away with the huge diff before the reader noticed
> it.
>
> Addressed in this patch.
>
> Am I missing something [...] ?
>
> Note that this parsing is used for both the parsing from command line
> as well as options, i.e.
Hmph, is it our convention for a value that is not yet known to the
current version of Git found in a configuration file to cause it to
die? I somehow thought that command line options are checked more
strictly and configuration variables are parsed more leniently.
If that is the case, the place that dies need to be raised in the
callchain; iow, instead of dying inside the parser, it is necessary
to let it only detect a problem and allow the caller to decide what
to do with the problem, I would think.
> git config diff.colorMovedWS asdf
> git format-patch HEAD^
> fatal: ignoring unknown color-moved-ws mode 'asdf'
> git config --unset diff.colorMovedWS
>
> (format-patch parses these color specific things, but doesn't apply it)
>
> diff.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/diff.c b/diff.c
> index 145cfbae59..bdf4535d69 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -313,7 +313,7 @@ static int parse_color_moved_ws(const char *arg)
> else if (!strcmp(sb.buf, "allow-indentation-change"))
> ret |= COLOR_MOVED_WS_ALLOW_INDENTATION_CHANGE;
> else
> - error(_("ignoring unknown color-moved-ws mode '%s'"), sb.buf);
> + die(_("ignoring unknown color-moved-ws mode '%s'"), sb.buf);
>
> strbuf_release(&sb);
> }
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: `--rebase-merges' still failing badly
2018-10-10 18:51 ` `--rebase-merges' still failing badly Michael Witten
2018-10-10 19:00 ` Michael Witten
2018-10-10 23:01 ` Junio C Hamano
@ 2018-10-12 9:11 ` Johannes Schindelin
2 siblings, 0 replies; 34+ messages in thread
From: Johannes Schindelin @ 2018-10-12 9:11 UTC (permalink / raw)
To: Michael Witten; +Cc: Junio C Hamano, Brian M. Carlson, Pratik Karki, git
Hi Michael,
On Wed, 10 Oct 2018, Michael Witten wrote:
> In my opinion, the `--rebase-merges' feature has been broken since the
> beginning, and the builtin version should be fixed before it is moved
> ahead.
Everybody is entitled to an opinion. My opinion differs from yours, and I
am a heavy user of `git rebase -kir`.
The `--rebase-merges` feature is not without problems, of course. I can
name a couple of bugs, but I have a hunch that it is more efficient for me
to just fix them.
> In short: "labels" are brittle; see below for tests.
Sure, let's improve them.
> Also, here are some quick *additional* thoughts:
>
> * Labels should be simply "r0", "r1", ... "rN".
That would not be an improvement.
The *interactive* version of `--rebase-merges` is what I use extensively
to juggle Git for Windows' branch thicket. It would be really bad if I had
to somehow map those label names in my head, rather than having the
intuitively-understood labels.
I would understand if you suggested to try to come up with a better naming
than `branch-point-<n>`. But `r<n>`? That's worse than the current state.
By a lot.
> * Why is the command "label" and not "branch"?
Because it is more versatile than just a branch. It is also branch points.
As a matter of fact, the very first statement is about the `onto` label,
which is not a branch.
> * In my experience, there's a lot of this boiler plate:
>
> pick 12345
> label r1
> reset r0
> merge r1
>
> How about instead, use git's existing ideas:
>
> pick 12345
> reset r0
> merge ORIG_HEAD
Too magic. And you cannot change it easily. I had this very real example,
a couple of times yesterday: A merge was in one of the "branches", and
needed to be moved out of it:
pick abc
label branch-point
merge -C 0123 topic
pick def
label bug-fix
reset branch-point
merge -C 4567 bug-fix
This `merge -C 0123 topic` needed to be moved before the branch point.
Another example where the explicit labeling comes in *real* handy is when
I made a Pull Request in Git for Windows ready for contribution to core
Git. These Pull Requests are normally based on `master`, because that is
what the best PR flow is: you based your contributions as close to the tip
as possible, to avoid merge conflicts (and to test as close to the real,
after-merge thing). This would look like this:
label branch-point
pick 123
pick 456
label pr-0815
reset branch-point
merge -C abc pr-0815
Now, to prepare this for core Git, I have to graft this PR onto the
`master` of *upstream*, in our case I would use the `onto` label for that,
by inserting a `reset onto` just before `pick 123`.
So you see, the current, non-implicit, but very much explicit syntax,
makes all of these tasks *quite* easy, and more importantly,
straight-forward: I did not have to explain this to anyone who I needed to
teach how this works.
Remember: the syntax of the todo list is not optimized to be short. It is
optimized to be *editable*. I need to have a very easy way to juggle
criss-cross-merging branch thickets. And the current syntax, while
chattier than you would like, does the job. Pretty well, even.
> * Why not just `--merges' instead of `--rebase-merges'?
This ship has sailed. It is pointless to discuss this now.
Besides, I believe that in your quest to shorten things, you unfortunately
shortened things too much: it is no longer clear what "merges" means in
the context of `--merges`.
> Unfortunately, both the legacy version and the rewrite of
> `--rebase-merges' display a bug that makes this feature fairly
> unusable in practice;
You will be surprised just how much I would embrace bug fixes, once you
provide any.
> it tries to create a "label" (i.e., a branch name) from a commit log
> summary line, and the result is often invalid (or just plain
> irritating to work with). In particular, it fails on typical
> characters, including at least these:
>
> :/\?.*[]
And of course those are not the only ones. The trick is to reduce runs of
disallowed characters to dashes, as is already done with spaces.
Ciao,
Johannes
>
> To see this, first define some POSIX shell functions:
>
> test()
> {
> (
> set -e
> summary=$1
> d=/tmp/repo ##### WARNING. CHANGE IF NECESSARY.
> rm -rf "$d"; mkdir -p "$d"; cd "$d"
> git init -q
> echo a > a; git add a; git commit -q -m a
> git branch base
> echo b > b; git add b; git commit -q -m b
> git reset -q --hard HEAD^
> git merge -q --no-ff -m "$summary" ORIG_HEAD
> git log --graph --oneline
> git rebase --rebase-merges base
> ); status=$?
> echo
> return "$status"
> }
>
> Test()
> {
> if test "$@" 1>/dev/null 2>&1; then
> echo ' good'; return 0
> else
> echo ' fail'; return 1
> fi
> }
>
> Then, try various commit summaries (see below for results):
>
> test c
> test 'combine these into a merge: a and b'
> Test ab:
> Test a:b
> Test :
> Test a/b
> Test 'Now supports /regex/'
> Test ab/
> Test /ab
> Test /
> Test 'a\b'
> Test '\'
> Test 'Maybe this works?'
> Test '?'
> Test 'This does not work.'
> Test 'This works. Strange!'
> Test .git
> Test .
> Test 'Cast each pointer to *void'
> Test '*'
> Test 'return a[1] not a[0]'
> Test '[ does not work'
> Test '['
> Test '] does work'
> Test ']'
>
> Here are the results of pasting the above commands into my terminal:
>
> $ test c
> warning: templates not found in ../install/share/git-core/templates
> * 1992d07 (HEAD -> master) c
> |\
> | * 34555b5 b
> |/
> * 338db9b (base) a
> Successfully rebased and updated refs/heads/master.
>
> $ test 'combine these into a merge: a and b'
> warning: templates not found in ../install/share/git-core/templates
> * 4202c49 (HEAD -> master) combine these into a merge: a and b
> |\
> | * 34555b5 b
> |/
> * 338db9b (base) a
> error: refusing to update ref with bad name 'refs/rewritten/combine-these-into-a-merge:-a-and-b'
> hint: Could not execute the todo command
> hint:
> hint: label combine-these-into-a-merge:-a-and-b
> hint:
> hint: It has been rescheduled; To edit the command before continuing, please
> hint: edit the todo list first:
> hint:
> hint: git rebase --edit-todo
> hint: git rebase --continue
>
> $ Test ab:
> fail
> $ Test a:b
> fail
> $ Test :
> fail
> $ Test a/b
> good
> $ Test 'Now supports /regex/'
> fail
> $ Test ab/
> fail
> $ Test /ab
> fail
> $ Test /
> fail
> $ Test 'a\b'
> fail
> $ Test '\'
> fail
> $ Test 'Maybe this works?'
> fail
> $ Test '?'
> fail
> $ Test 'This does not work.'
> fail
> $ Test 'This works. Strange!'
> good
> $ Test .git
> fail
> $ Test .
> fail
> $ Test 'Cast each pointer to *void'
> fail
> $ Test '*'
> fail
> $ Test 'return a[1] not a[0]'
> fail
> $ Test '[ does not work'
> fail
> $ Test '['
> fail
> $ Test '] does work'
> good
> $ Test ']'
> good
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-11 22:40 ` Junio C Hamano
2018-10-11 22:59 ` [PATCH] diff.c: die on unknown color-moved ws mode Stefan Beller
2018-10-11 23:06 ` What's cooking in git.git (Oct 2018, #01; Wed, 10) Stefan Beller
@ 2018-10-12 9:59 ` Phillip Wood
2018-10-12 13:36 ` Junio C Hamano
2 siblings, 1 reply; 34+ messages in thread
From: Phillip Wood @ 2018-10-12 9:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Stefan Beller
On 11/10/2018 23:40, Junio C Hamano wrote:
> Phillip Wood <phillip.wood@talktalk.net> writes:
>
>> On 10/10/2018 06:43, Junio C Hamano wrote:
>>> Here are the topics that have been cooking. Commits prefixed with
>>> '-' are only in 'pu' (proposed updates) while commits prefixed with
>>> '+' are in 'next'. The ones marked with '.' do not appear in any of
>>> the integration branches, but I am still holding onto them.
>>>
>>> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
>>> - diff --color-moved: fix a memory leak
>>> - diff --color-moved-ws: fix another memory leak
>>> - diff --color-moved-ws: fix a memory leak
>>> - diff --color-moved-ws: fix out of bounds string access
>>> - diff --color-moved-ws: fix double free crash
>>>
>>> Various fixes to "diff --color-moved-ws".
>>>
>>> What's the status of this topic?
>>
>> I think it is ready for next - Stefan was happy with the last iteration.
>
> This is not about your fixes, but I was skimming the color-moved
> support in general as a final sanity check to move this forward and
> noticed that
>
> $ git diff --color-moved-ws=ignore-any master...
>
> does not do anything interesting, which is broken at at least two
> points.
>
> * There is no "ignore-any" supported by the feature---I think that
> the parser for the option should have noticed and barfed, but it
> did not. It merely emitted a message to the standard output and
> let it scroll away with the huge diff before the reader noticed
> it.
It would be nice if the parsing used starts_with(option_name, user_text)
rather than strcmp() as well. Also I think --color-moved=no is valid as
a synonym of --no-color-moved but --color-moved-ws=no is not supported.
> * After fixing ignore-any to one of the supported option
> (e.g. "ignore-all-spaces"), the color-moved feature still did not
> trigger. I think the presence of --color-moved-ws by itself is a
> hint that the user wants --color-moved to be used. If it turns
> out that there are some valid use cases where --color-moved-ws
> may have to be set but the color-moved feature should not be
> enabled, then
>
> diff --color-moved-ws=ignore-all-space --no-color-moved
>
> can be used to countermand this, of course.
>
> Am I missing something or are these mere small sloppiness in the
> current code?
>
>
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-12 9:59 ` Phillip Wood
@ 2018-10-12 13:36 ` Junio C Hamano
2018-10-16 13:38 ` Phillip Wood
0 siblings, 1 reply; 34+ messages in thread
From: Junio C Hamano @ 2018-10-12 13:36 UTC (permalink / raw)
To: Phillip Wood; +Cc: git, Stefan Beller
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-10 5:43 What's cooking in git.git (Oct 2018, #01; Wed, 10) Junio C Hamano
` (9 preceding siblings ...)
2018-10-11 11:16 ` Derrick Stolee
@ 2018-10-14 12:21 ` Duy Nguyen
10 siblings, 0 replies; 34+ messages in thread
From: Duy Nguyen @ 2018-10-14 12:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
On Wed, Oct 10, 2018 at 7:43 AM Junio C Hamano <gitster@pobox.com> wrote:
> * nd/per-worktree-ref-iteration (2018-10-07) 9 commits
> - SQUASH???
> - reflog expire: cover reflog from all worktrees
> - fsck: check HEAD and reflog from other worktrees
> - fsck: Move fsck_head_link() to get_default_heads() to avoid some globals
> - revision.c: better error reporting on ref from different worktrees
> - revision.c: correct a parameter name
> - refs: new ref types to make per-worktree refs visible to all worktrees
> - Add a place for (not) sharing stuff between worktrees
> - refs.c: indent with tabs, not spaces
>
> What's the status of this topic?
There's one bug spotted by Eric and a few test cases to be added in
the reflog patch.
--
Duy
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-12 13:36 ` Junio C Hamano
@ 2018-10-16 13:38 ` Phillip Wood
2018-10-16 17:13 ` Stefan Beller
0 siblings, 1 reply; 34+ messages in thread
From: Phillip Wood @ 2018-10-16 13:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Stefan Beller
On 12/10/2018 14:36, Junio C Hamano wrote:
> Phillip Wood <phillip.wood@talktalk.net> writes:
>
>> It would be nice if the parsing used starts_with(option_name, user_text)
>> rather than strcmp() as well. Also I think --color-moved=no is valid as
>> a synonym of --no-color-moved but --color-moved-ws=no is not supported.
>
> I am not sure about starts_with(). Do you mean we should accept
> "--color-mo", as that is a prefix of "--color-moved" that is not
> shared with any existing option, until we gain a different option
> "--color-more"?
I was thinking of the option arguments rather than the option names
although being able to abbreviate the names in the same way as the
commands that parse_options() would be good too (I seem to remember
someone saying they had some rough patches to use parse_options() for
diff and log in a discussion of adding completion support to
parse_options())
> If you mean "--color-moved-ws=no" (or "--no-color-moved-ws") as a
> way to countermand an earlier --color-moved-ws=<something> on the
> command line, I fully agree that it is a good idea.
Oh I assumed --no-color-moved-ws was allowed but it isn't it. Allowing
--color-moved-ws=no as well would match what is allowed for
--color-moved. I'll try and look at that.
Best Wishes
Phillip
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
2018-10-16 13:38 ` Phillip Wood
@ 2018-10-16 17:13 ` Stefan Beller
0 siblings, 0 replies; 34+ messages in thread
From: Stefan Beller @ 2018-10-16 17:13 UTC (permalink / raw)
To: Phillip Wood; +Cc: Junio C Hamano, git
On Tue, Oct 16, 2018 at 6:39 AM Phillip Wood <phillip.wood@talktalk.net> wrote:
> > If you mean "--color-moved-ws=no" (or "--no-color-moved-ws") as a
> > way to countermand an earlier --color-moved-ws=<something> on the
> > command line, I fully agree that it is a good idea.
>
> Oh I assumed --no-color-moved-ws was allowed but it isn't it. Allowing
> --color-moved-ws=no as well would match what is allowed for
> --color-moved. I'll try and look at that.
Thanks for taking a look!
Stefan
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2018-10-16 17:14 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-10 5:43 What's cooking in git.git (Oct 2018, #01; Wed, 10) Junio C Hamano
2018-10-10 7:59 ` Ævar Arnfjörð Bjarmason
2018-10-10 15:06 ` Jeff King
2018-10-10 12:57 ` builtin stash/rebase, was " Johannes Schindelin
2018-10-10 13:19 ` Junio C Hamano
2018-10-11 2:18 ` Junio C Hamano
2018-10-10 13:04 ` js/mingw-wants-vista-or-above, " Johannes Schindelin
2018-10-10 13:13 ` Junio C Hamano
2018-10-10 13:58 ` Phillip Wood
2018-10-11 1:54 ` Junio C Hamano
2018-10-11 22:40 ` Junio C Hamano
2018-10-11 22:59 ` [PATCH] diff.c: die on unknown color-moved ws mode Stefan Beller
2018-10-11 23:01 ` Stefan Beller
2018-10-12 1:22 ` Junio C Hamano
2018-10-11 23:06 ` What's cooking in git.git (Oct 2018, #01; Wed, 10) Stefan Beller
2018-10-12 0:51 ` Junio C Hamano
2018-10-12 9:59 ` Phillip Wood
2018-10-12 13:36 ` Junio C Hamano
2018-10-16 13:38 ` Phillip Wood
2018-10-16 17:13 ` Stefan Beller
2018-10-10 14:18 ` Thomas Gummerer
2018-10-11 1:40 ` Junio C Hamano
2018-10-10 18:51 ` `--rebase-merges' still failing badly Michael Witten
2018-10-10 19:00 ` Michael Witten
2018-10-10 23:01 ` Junio C Hamano
2018-10-11 2:44 ` Michael Witten
2018-10-12 9:11 ` Johannes Schindelin
2018-10-10 18:55 ` What's cooking in git.git (Oct 2018, #01; Wed, 10) Stefan Beller
2018-10-11 2:00 ` Junio C Hamano
2018-10-10 20:38 ` Tim Schumacher
2018-10-10 21:25 ` Johannes Sixt
2018-10-11 1:53 ` Junio C Hamano
2018-10-11 11:16 ` Derrick Stolee
2018-10-14 12:21 ` Duy Nguyen
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).