* What's cooking in git.git (Sep 2020, #03; Wed, 9)
@ 2020-09-09 22:32 Junio C Hamano
2020-09-09 23:07 ` Eric Sunshine
2020-09-15 19:05 ` Jakub Narębski
0 siblings, 2 replies; 13+ messages in thread
From: Junio C Hamano @ 2020-09-09 22:32 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'seen' (formerly 'pu'---proposed updates) while commits prefixed
with '+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to 'master']
* es/worktree-repair (2020-08-31) 5 commits
(merged to 'next' on 2020-08-31 at 604825c5e4)
+ init: make --separate-git-dir work from within linked worktree
+ init: teach --separate-git-dir to repair linked worktrees
+ worktree: teach "repair" to fix outgoing links to worktrees
+ worktree: teach "repair" to fix worktree back-links to main worktree
+ worktree: add skeleton "repair" command
"git worktree" gained a "repair" subcommand to help users recover
after moving the worktrees or repository manually without telling
Git. Also, "git init --separate-git-dir" no longer corrupts
administrative data related to linked worktrees.
* hv/ref-filter-misc (2020-08-28) 8 commits
(merged to 'next' on 2020-09-02 at 9a8bb84f20)
+ ref-filter: add `sanitize` option for 'subject' atom
+ pretty: refactor `format_sanitized_subject()`
+ ref-filter: add `short` modifier to 'parent' atom
+ ref-filter: add `short` modifier to 'tree' atom
+ ref-filter: rename `objectname` related functions and fields
+ ref-filter: modify error messages in `grab_objectname()`
+ ref-filter: refactor `grab_objectname()`
+ ref-filter: support different email formats
The "--format=" option to the "for-each-ref" command and friends
learned a few more tricks, e.g. the ":short" suffix that applies to
"objectname" now also can be used for "parent", "tree", etc.
* jk/worktree-check-clean-leakfix (2020-08-27) 1 commit
(merged to 'next' on 2020-08-31 at 220fc43629)
+ worktree: fix leak in check_clean_worktree()
Leakfix.
* js/ci-squelch-false-failure (2020-09-02) 2 commits
(merged to 'next' on 2020-09-03 at 254f390305)
+ ci: avoid ugly "failure" in the `ci-config` job
+ ci: fix indentation of the `ci-config` job
CI noise reduction.
* jt/interpret-branch-name-fallback (2020-09-02) 3 commits
(merged to 'next' on 2020-09-03 at 28914ab788)
+ wt-status: tolerate dangling marks
+ refs: move dwim_ref() to header file
+ sha1-name: replace unsigned int with option struct
"git status" has trouble showing where it came from by interpreting
reflog entries that recordcertain events, e.g. "checkout @{u}", and
gives a hard/fatal error. Even though it inherently is impossible
to give a correct answer because the reflog entries lose some
information (e.g. "@{u}" does not record what branch the user was
on hence which branch 'the upstream' needs to be computed, and even
if the record were available, the relationship between branches may
have changed), at least hide the error to allow "status" show its
output.
* os/vcbuild (2020-09-08) 3 commits
(merged to 'next' on 2020-09-08 at 56551401c2)
+ contrib/buildsystems: fix expat library name for generated vcxproj
(merged to 'next' on 2020-09-03 at 0216ec9cb9)
+ vcbuild: fix batch file name in README
+ vcbuild: fix library name for expat with make MSVC=1
Fix build procedure for MSVC.
* pb/imap-send-updates (2020-08-31) 3 commits
(merged to 'next' on 2020-09-02 at 899fca3919)
+ git-imap-send.txt: add note about localized Gmail folders
+ git-imap-send.txt: do verify SSL certificate for gmail.com
+ git-imap-send.txt: don't duplicate 'Examples' sections
"git imap-send" updates.
* so/separate-field-for-m-and-diff-merges (2020-08-31) 1 commit
(merged to 'next' on 2020-08-31 at 8def2984ca)
+ revision: add separate field for "-m" of "diff-index -m"
Internal API clean-up to handle two options "diff-index" and "log"
have, which happen to share the same short form, more sensibly.
* ss/submodule-summary-in-c (2020-08-12) 4 commits
(merged to 'next' on 2020-08-17 at 9bc352cb70)
+ submodule: port submodule subcommand 'summary' from shell to C
+ t7421: introduce a test script for verifying 'summary' output
+ submodule: rename helper functions to avoid ambiguity
+ submodule: remove extra line feeds between callback struct and macro
(this branch is used by ss/submodule-summary-in-c-fixes.)
Yet another subcommand of "git submodule" is getting rewritten in C.
* ss/submodule-summary-in-c-fixes (2020-08-27) 3 commits
(merged to 'next' on 2020-09-02 at 7f959811b8)
+ t7421: eliminate 'grep' check in t7421.4 for mingw compatibility
+ submodule: fix style in function definition
+ submodule: eliminate unused parameters from print_submodule_summary()
(this branch uses ss/submodule-summary-in-c.)
Fixups to a topic in 'next'.
* tb/repack-clearing-midx (2020-08-28) 2 commits
(merged to 'next' on 2020-08-28 at 4204c0cb5e)
+ midx: traverse the local MIDX first
(merged to 'next' on 2020-08-27 at a465875cbb)
+ builtin/repack.c: invalidate MIDX only when necessary
When a packfile is removed by "git repack", multi-pack-index gets
cleared; the code was taught to do so less aggressively by first
checking if the midx actually refers to a pack that no longer
exists.
--------------------------------------------------
[New Topics]
* al/t3200-back-on-a-branch (2020-09-08) 1 commit
(merged to 'next' on 2020-09-09 at 833e2fc60c)
+ t3200: clean side effect of git checkout --orphan
Test fix.
Will merge to 'master'.
* bc/rev-parse-path-format (2020-09-08) 1 commit
- rev-parse: add option for absolute or relative path formatting
"git rev-parse" can be explicitly told to give output as absolute
or relative path.
* ds/maintenance-part-3 (2020-09-06) 6 commits
- maintenance: recommended schedule in register/start
- maintenance: add start/stop subcommands
- maintenance: add [un]register subcommands
- for-each-repo: run subcommands on configured repos
- maintenance: add --schedule option and config
- maintenance: optionally skip --auto process
(this branch uses ds/maintenance-part-1 and ds/maintenance-part-2.)
Parts of "git maintenance" to ease writing crontab entries (and
other scheduling system configuration) for it.
* ea/blame-use-oideq (2020-09-08) 1 commit
(merged to 'next' on 2020-09-09 at babefe4727)
+ blame.c: replace instance of !oidcmp for oideq
Code cleanup.
Will merge to 'master'.
* es/format-patch-interdiff-cleanup (2020-09-08) 3 commits
- format-patch: use 'origin' as start of current-series-range when known
- diff-lib: tighten show_interdiff()'s interface
- diff: move show_interdiff() from its own file to diff-lib
Code cleanup with a slight behaviour change when "format-patch
--range-diff=<prev> origin..HEAD" gives a single revision to
<prev>.
Will merge to 'next'.
* es/wt-add-detach (2020-09-06) 3 commits
- git-worktree.txt: discuss branch-based vs. throwaway worktrees
- worktree: teach `add` to recognize -d as shorthand for --detach
- git-checkout.txt: document -d short option for --detach
"git worktree add" learns the "--detach" option to create a new
worktree without being on a branch.
Will merge to 'next'.
* hn/refs-ref-log-only-bit (2020-09-08) 1 commit
(merged to 'next' on 2020-09-09 at f729cb2c81)
+ refs: move REF_LOG_ONLY to refs-internal.h
A bit of API reshuffling to make sure stuff common to all backends
are not defined only in files backend.
Will merge to 'master'.
* jc/add-i-use-builtin-experimental (2020-09-08) 1 commit
(merged to 'next' on 2020-09-09 at abcb7515dc)
+ add -i: use the built-in version when feature.experimental is set
The "add -i/-p" machinery has been written in C but it is not used
by default yet. It is made default to those who are participating
in feature.experimental experiment.
Will merge to 'master'.
* jc/quote-path-cleanup (2020-09-08) 6 commits
- quote: turn 'nodq' parameter into a set of flags
- quote: rename misnamed sq_lookup[] to cq_lookup[]
- wt-status: consistently quote paths in "status --short" output
- quote_path: optionally allow quoting a path with SP in it
- quote_path: give flags parameter to quote_path()
- quote_path: rename quote_path_relative() to quote_path()
"git status --short" quoted a path with SP in it when tracked, but
not those that are untracked, ignored or unmerged. They are all
shown quoted consistently.
Undecided.
This is more involved than alternatives proposed by brian and Réne
and I am not sure extra changes to the codebase is a net positive.
cf. <20200908013013.1099937-1-sandals@crustytoothpaste.net>
cf. <3a72c5f2-35cc-a865-d5f2-02706c48d8ec@web.de>
* jk/add-i-fixes (2020-09-08) 2 commits
(merged to 'next' on 2020-09-09 at 46ea071a7a)
+ add--interactive.perl: specify --no-color explicitly
+ add-patch: fix inverted return code of repo_read_index()
"add -i/-p" fixes.
Will merge to 'master'.
* os/collect-changed-submodules-optim (2020-09-06) 1 commit
- submodule: suppress checking for file name and ref ambiguity for object ids
Optimization around submodule handling.
Will merge to 'next'.
* os/fetch-submodule-optim (2020-09-06) 1 commit
- fetch: do not look for submodule changes in unchanged refs
Optimization around submodule handling.
Will merge to 'next'.
* pw/add-p-edit-ita-path (2020-09-09) 1 commit
- add -p: fix editing of intent-to-add paths
"add -p" did not allow editing paths that were only added in
intent.
Will merge to 'next'.
* pw/add-p-leakfix (2020-09-08) 1 commit
(merged to 'next' on 2020-09-09 at 4206d0503c)
+ add -p: fix memory leak
Leakfix.
Will merge to 'master'.
* rs/misc-cleanups (2020-09-06) 3 commits
(merged to 'next' on 2020-09-09 at 4a19ea9672)
+ pack-bitmap-write: use hashwrite_be32() in write_hash_cache()
+ midx: use hashwrite_u8() in write_midx_header()
+ fast-import: use write_pack_header()
Misc cleanups.
Will merge to 'master'.
* rs/parallel-read-cache-fix (2020-09-06) 1 commit
(merged to 'next' on 2020-09-09 at 92953a75c4)
+ read-cache: fix mem-pool allocation for multi-threaded index loading
A follow-up fix to a topic already in 'master'.
Will merge to 'master'.
* rs/refspec-leakfix (2020-09-06) 2 commits
(merged to 'next' on 2020-09-09 at 10741e90a5)
+ refspec: add and use refspec_appendf()
+ push: release strbufs used for refspec formatting
Leakfix.
Will merge to 'master'.
* so/log-tree-diff-cleanup (2020-09-06) 2 commits
(merged to 'next' on 2020-09-09 at f8744b8e8a)
+ log_tree_diff: get rid of extra check for NULL
+ log_tree_diff: get rid of code duplication for first_parent_only
Code cleanup.
Will merge to 'master'.
* hn/refs-trace-backend (2020-09-09) 1 commit
- refs: add GIT_TRACE_REFS debugging mechanism
Developer support.
Will merge to 'next'.
* jc/dist-tarball-tweak (2020-09-09) 1 commit
- Makefile: allow extra tweaking of distribution tarball
Allow maintainers to tweak $(TAR) invocations done while making
distribution tarballs.
Will merge to 'next'.
* mt/config-fail-nongit-early (2020-09-09) 1 commit
- config: complain about --worktree outside of a git repo
Unlike "git config --local", "git config --worktree" did not fail
early and cleanly when started outside a git repository.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* vv/send-email-with-less-secure-apps-access (2020-08-29) 1 commit
- Documentation/git-send-email.txt: Mention less secure app access might need to enable.
Doc update.
Expecting a reroll.
cf. <xmqqwo1hi9nv.fsf@gitster.c.googlers.com>
cf. <xmqqft85i72s.fsf@gitster.c.googlers.com>
* jc/war-on-dashed-git (2020-08-27) 1 commit
- git: catch an attempt to run "git-foo"
The first step to remove on-disk binaries for built-in subcommands
by soliciting objections.
On hold for now.
* dr/push-remoteref-fix (2020-04-23) 1 commit
- remote.c: fix handling of %(push:remoteref)
The "%(push:remoteref)" placeholder in the "--format=" argument of
"git format-patch" (and friends) only showed what got explicitly
configured, not what ref at the receiving end would be updated when
"git push" was used, as it ignored the default behaviour (e.g. update
the same ref as the source).
Expecting a reroll.
cf. <20200416152145.wp2zeibxmuyas6y6@feanor>
cf. <xmqqv9gu7c61.fsf@gitster.c.googlers.com>
* mk/use-size-t-in-zlib (2018-10-15) 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".
--------------------------------------------------
[Cooking]
* tb/bloom-improvements (2020-09-09) 12 commits
- builtin/commit-graph.c: introduce '--max-new-filters=<n>'
- commit-graph: rename 'split_commit_graph_opts'
- bloom: encode out-of-bounds filters as non-empty
- bloom/diff: properly short-circuit on max_changes
- bloom: use provided 'struct bloom_filter_settings'
- bloom: split 'get_bloom_filter()' in two
- commit-graph.c: store maximum changed paths
- commit-graph: respect 'commitGraph.readChangedPaths'
- t/helper/test-read-graph.c: prepare repo settings
- commit-graph: pass a 'struct repository *' in more places
- t4216: use an '&&'-chain
- commit-graph: introduce 'get_bloom_filter_settings()'
"git commit-graph write" learned to limit the number of bloom
filters that are computed from scratch with the --max-new-filters
option.
* es/config-hooks (2020-09-09) 9 commits
- run_commit_hook: take strvec instead of varargs
- commit: use config-based hooks
- hook: replace run-command.h:find_hook
- hook: add 'run' subcommand
- parse-options: parse into strvec
- hook: add --porcelain to list command
- hook: add list command
- hook: scaffolding for git-hook subcommand
- doc: propose hooks managed by the config
The "hooks defined in config" topic.
* ls/mergetool-meld-auto-merge (2020-09-09) 1 commit
- Support auto-merge for meld to follow the vim-diff behavior
The 'meld' backend of the "git mergetool" learned to give the
underlying 'meld' the '--auto-merge' option, which would help
reduce the amount of text that requires manual merging.
Will merge to 'next'.
* mf/submodule-summary-with-correct-repository (2020-06-24) 2 commits
- submodule: use submodule repository when preparing summary
- revision: use repository from rev_info when parsing commits
"git diff/show" on a change that involves a submodule used to read
the information on commits in the submodule from a wrong repository
and gave a wrong information when the commit-graph is involved.
Will merge to 'next'.
cf. <xmqqzh667ca4.fsf@gitster.c.googlers.com>
* pb/clang-json-compilation-database (2020-09-06) 1 commit
(merged to 'next' on 2020-09-09 at 9f5ea136f1)
+ Makefile: add support for generating JSON compilation database
Developer support.
Will merge to 'master'.
* mt/grep-sparse-checkout (2020-09-02) 8 commits
- config: add setting to ignore sparsity patterns in some cmds
- grep: honor sparse checkout patterns
- config: correctly read worktree configs in submodules
- t/helper/test-config: unify exit labels
- t/helper/test-config: check argc before accessing argv
- t/helper/test-config: be consistent with exit codes
- t1308-config-set: avoid false positives when using test-config
- doc: grep: unify info on configuration variables
"git grep" has been tweaked to be limited to the sparse checkout
paths.
* ew/decline-core-abbrev (2020-09-01) 1 commit
- core.abbrev <off|false|no> disables abbreviations
Allow the configuration to specify no abbreviation regardless of
the hash algorithm.
Expecting a reroll. The intent is very good.
* mr/bisect-in-c-2 (2020-08-31) 13 commits
- bisect--helper: retire `--bisect-autostart` subcommand
- bisect--helper: retire `--write-terms` subcommand
- bisect--helper: retire `--check-expected-revs` subcommand
- bisect--helper: reimplement `bisect_state` & `bisect_head` shell functions in C
- bisect--helper: retire `--next-all` subcommand
- bisect--helper: retire `--bisect-clean-state` subcommand
- bisect--helper: finish porting `bisect_start()` to C
- bisect--helper: reimplement `bisect_next` and `bisect_auto_next` shell functions in C
- bisect: call 'clear_commit_marks_all()' in 'bisect_next_all()'
- bisect--helper: reimplement `bisect_autostart` shell function in C
- bisect--helper: introduce new `write_in_file()` function
- bisect--helper: use '-res' in 'cmd_bisect__helper' return
- bisect--helper: BUG() in cmd_*() on invalid subcommand
Rewrite of the "git bisect" script in C continues.
At v7; getting close
cf. <nycvar.QRO.7.76.6.2009031403510.56@tvgsbejvaqbjf.bet>
* js/no-builtins-on-disk-option (2020-08-24) 3 commits
- ci: stop linking built-ins to the dashed versions
- install: optionally skip linking/copying the built-ins
- msvc: copy the correct `.pdb` files in the Makefile target `install`
The installation procedure learned to optionally omit "git-foo"
executable files for each 'foo' built-in subcommand, which are only
required by old timers that still rely on the age old promise that
prepending "git --exec-path" output to PATH early in their script
will keep the "git-foo" calls they wrote working.
The old attempt to remove these executables from the disk failed in
the 1.6 era; it may be worth attempting again, but I think it is
worth to keep this topic separate from such a policy change to help
it graduate early.
Expecting a reroll to update log message for the last one.
as it confused at least two reviewers.
cf. <xmqqwo1baop3.fsf@gitster.c.googlers.com>
cf. <20200903104537.GA27325@szeder.dev>
* jt/threaded-index-pack (2020-09-08) 7 commits
- index-pack: make quantum of work smaller
- index-pack: make resolve_delta() assume base data
- index-pack: calculate {ref,ofs}_{first,last} early
- index-pack: remove redundant child field
- index-pack: unify threaded and unthreaded code
- index-pack: remove redundant parameter
- Documentation: deltaBaseCacheLimit is per-thread
"git index-pack" learned to resolve deltified objects with greater
parallelism.
Will merge to 'next'.
* jk/refspecs-negative (2020-08-21) 1 commit
- refspec: add support for negative refspecs
"negative refspecs"
* jx/proc-receive-hook (2020-08-27) 10 commits
- doc: add documentation for the proc-receive hook
- transport: parse report options for tracking refs
- t5411: test updates of remote-tracking branches
- receive-pack: new config receive.procReceiveRefs
- doc: add document for capability report-status-v2
- New capability "report-status-v2" for git-push
- receive-pack: feed report options to post-receive
- receive-pack: add new proc-receive hook
- t5411: add basic test cases for proc-receive hook
- transport: not report a non-head push as a branch
"git receive-pack" that accepts requests by "git push" learned to
outsource most of the ref updates to the new "proc-receive" hook.
Will merge to 'next'.
* ds/maintenance-part-2 (2020-09-06) 8 commits
- maintenance: add incremental-repack auto condition
- maintenance: auto-size incremental-repack batch
- maintenance: add incremental-repack task
- midx: use start_delayed_progress()
- midx: enable core.multiPackIndex by default
- maintenance: create auto condition for loose-objects
- maintenance: add loose-objects task
- maintenance: add prefetch task
(this branch is used by ds/maintenance-part-3; uses ds/maintenance-part-1.)
"git maintenance", an extended big brother of "git gc", continues
to evolve.
* ds/maintenance-part-1 (2020-09-06) 11 commits
- maintenance: add trace2 regions for task execution
- maintenance: add auto condition for commit-graph task
- maintenance: use pointers to check --auto
- maintenance: create maintenance.<task>.enabled config
- maintenance: take a lock on the objects directory
- maintenance: add --task option
- maintenance: add commit-graph task
- maintenance: initialize task array
- maintenance: replace run_auto_gc()
- maintenance: add --quiet option
- maintenance: create basic maintenance runner
(this branch is used by ds/maintenance-part-2 and ds/maintenance-part-3.)
A "git gc"'s big brother has been introduced to take care of more
repository maintenance tasks, not limited to the object database
cleaning.
Will merge to 'next'.
--------------------------------------------------
[Discarded]
* jc/remove-pack-redundant (2020-08-25) 1 commit
. pack-redundant: gauge the usage before proposing its removal
The first step to remove "git pack-redundant" by soliciting
objections.
Stop--we had some activity as late as last year.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
2020-09-09 22:32 What's cooking in git.git (Sep 2020, #03; Wed, 9) Junio C Hamano
@ 2020-09-09 23:07 ` Eric Sunshine
2020-09-10 4:52 ` Junio C Hamano
2020-09-15 19:05 ` Jakub Narębski
1 sibling, 1 reply; 13+ messages in thread
From: Eric Sunshine @ 2020-09-09 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
On Wed, Sep 9, 2020 at 6:33 PM Junio C Hamano <gitster@pobox.com> wrote:
> * es/format-patch-interdiff-cleanup (2020-09-08) 3 commits
> - format-patch: use 'origin' as start of current-series-range when known
> - diff-lib: tighten show_interdiff()'s interface
> - diff: move show_interdiff() from its own file to diff-lib
>
> Code cleanup with a slight behaviour change when "format-patch
> --range-diff=<prev> origin..HEAD" gives a single revision to
> <prev>.
Perhaps this could be a bit more precise by saying something like:
Code cleanup and make "format-patch --range-diff=<prev>
<origin>..HEAD" not ignore <origin> when <prev> is a single
revision.
> * es/wt-add-detach (2020-09-06) 3 commits
> - git-worktree.txt: discuss branch-based vs. throwaway worktrees
> - worktree: teach `add` to recognize -d as shorthand for --detach
> - git-checkout.txt: document -d short option for --detach
>
> "git worktree add" learns the "--detach" option to create a new
> worktree without being on a branch.
This needs a tweak to avoid being incorrect. "git worktree add" has
understood --detach from the start. This series only teaches it -d as
an alias for --detach. So, perhaps:
"git worktree add" learns "-d" as short for "--detach".
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
2020-09-09 23:07 ` Eric Sunshine
@ 2020-09-10 4:52 ` Junio C Hamano
2020-09-15 22:48 ` Eric Sunshine
0 siblings, 1 reply; 13+ messages in thread
From: Junio C Hamano @ 2020-09-10 4:52 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Git List
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Wed, Sep 9, 2020 at 6:33 PM Junio C Hamano <gitster@pobox.com> wrote:
>> * es/format-patch-interdiff-cleanup (2020-09-08) 3 commits
>> - format-patch: use 'origin' as start of current-series-range when known
>> - diff-lib: tighten show_interdiff()'s interface
>> - diff: move show_interdiff() from its own file to diff-lib
>>
>> Code cleanup with a slight behaviour change when "format-patch
>> --range-diff=<prev> origin..HEAD" gives a single revision to
>> <prev>.
>
> Perhaps this could be a bit more precise by saying something like:
>
> Code cleanup and make "format-patch --range-diff=<prev>
> <origin>..HEAD" not ignore <origin> when <prev> is a single
> revision.
Sure. I didn't realize we can be more specific without spending too
many more bytes. Let me steal that description.
> "git worktree add" learns "-d" as short for "--detach".
Thanks.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
2020-09-09 22:32 What's cooking in git.git (Sep 2020, #03; Wed, 9) Junio C Hamano
2020-09-09 23:07 ` Eric Sunshine
@ 2020-09-15 19:05 ` Jakub Narębski
2020-09-15 19:32 ` Taylor Blau
2020-09-15 21:14 ` Junio C Hamano
1 sibling, 2 replies; 13+ messages in thread
From: Jakub Narębski @ 2020-09-15 19:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Abhishek Kumar, Derrick Stolee, Taylor Blau, Jakub Narębski
Hello,
Junio C Hamano <gitster@pobox.com> writes:
> * ss/submodule-summary-in-c (2020-08-12) 4 commits
> (merged to 'next' on 2020-08-17 at 9bc352cb70)
> + submodule: port submodule subcommand 'summary' from shell to C
> + t7421: introduce a test script for verifying 'summary' output
> + submodule: rename helper functions to avoid ambiguity
> + submodule: remove extra line feeds between callback struct and macro
> (this branch is used by ss/submodule-summary-in-c-fixes.)
>
> Yet another subcommand of "git submodule" is getting rewritten in C.
>
>
> * ss/submodule-summary-in-c-fixes (2020-08-27) 3 commits
> (merged to 'next' on 2020-09-02 at 7f959811b8)
> + t7421: eliminate 'grep' check in t7421.4 for mingw compatibility
> + submodule: fix style in function definition
> + submodule: eliminate unused parameters from print_submodule_summary()
> (this branch uses ss/submodule-summary-in-c.)
>
> Fixups to a topic in 'next'.
Those are patches that are part of GSoC project of Shourya Shukla:
'Convert submodule to builtin'.
> * hv/ref-filter-misc (2020-08-28) 8 commits
> (merged to 'next' on 2020-09-02 at 9a8bb84f20)
> + ref-filter: add `sanitize` option for 'subject' atom
> + pretty: refactor `format_sanitized_subject()`
> + ref-filter: add `short` modifier to 'parent' atom
> + ref-filter: add `short` modifier to 'tree' atom
> + ref-filter: rename `objectname` related functions and fields
> + ref-filter: modify error messages in `grab_objectname()`
> + ref-filter: refactor `grab_objectname()`
> + ref-filter: support different email formats
>
> The "--format=" option to the "for-each-ref" command and friends
> learned a few more tricks, e.g. the ":short" suffix that applies to
> "objectname" now also can be used for "parent", "tree", etc.
>
Those are patches that are part of GSoC project of Hariom Verma:
'Unify ref-filter formats with other --pretty formats'
I'd like to point out that latest series of patches by Abhishek Kumar
which are final part of 'Implement Generation Number v2' is at what I
believe is next to final iteration:
"[PATCH v3 00/11] [GSoC] Implement Corrected Commit Date"
https://lore.kernel.org/git/pull.676.v3.git.1597509583.gitgitgadget@gmail.com/T/#u
It is waiting for the decision on *how to implement storing* new
generation number in the commit-graph file: should we store corrected
commit date directly as 64 bit value, or should we store corrected
commit date offset as 32 bit value with overflow handling?
Switching from 64 bits to 32 bits halves the size of the GDAT
(Generation DATa) chunk, but decreases the size of the commit-graph file
by at most 7%. For large repository, like MS Windows with 3M commits in
2019 it would mean decreasing the size of the commit-graph file by
11.8 MiB (if I calculated it correctly).
Because corrected commit date offsets are not monotone, that is after
value that doesn't fit in 32 bits (in parent) there can be one that does
(in child). It is extremely unlikely that in real repositories there
would be that large corrections needed, but it can happen in theory, and
therfore we need some way to handle overflow if we choose this option.
And of course we should test that overflow handling works correctly.
So there is tradeoff between complexity and commit-graph file size.
Best,
--
Jakub Narębski
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
2020-09-15 19:05 ` Jakub Narębski
@ 2020-09-15 19:32 ` Taylor Blau
2020-09-15 21:14 ` Junio C Hamano
1 sibling, 0 replies; 13+ messages in thread
From: Taylor Blau @ 2020-09-15 19:32 UTC (permalink / raw)
To: Jakub Narębski
Cc: Junio C Hamano, git, Abhishek Kumar, Derrick Stolee, Taylor Blau
Hi Jakub,
On Tue, Sep 15, 2020 at 09:05:18PM +0200, Jakub Narębski wrote:
> I'd like to point out that latest series of patches by Abhishek Kumar
> which are final part of 'Implement Generation Number v2' is at what I
> believe is next to final iteration:
>
> "[PATCH v3 00/11] [GSoC] Implement Corrected Commit Date"
> https://lore.kernel.org/git/pull.676.v3.git.1597509583.gitgitgadget@gmail.com/T/#u
>
> It is waiting for the decision on *how to implement storing* new
> generation number in the commit-graph file: should we store corrected
> commit date directly as 64 bit value, or should we store corrected
> commit date offset as 32 bit value with overflow handling?
>
> Switching from 64 bits to 32 bits halves the size of the GDAT
> (Generation DATa) chunk, but decreases the size of the commit-graph file
> by at most 7%. For large repository, like MS Windows with 3M commits in
> 2019 it would mean decreasing the size of the commit-graph file by
> 11.8 MiB (if I calculated it correctly).
>
> Because corrected commit date offsets are not monotone, that is after
> value that doesn't fit in 32 bits (in parent) there can be one that does
> (in child). It is extremely unlikely that in real repositories there
> would be that large corrections needed, but it can happen in theory, and
> therfore we need some way to handle overflow if we choose this option.
> And of course we should test that overflow handling works correctly.
>
> So there is tradeoff between complexity and commit-graph file size.
If you think that not being able to fit into 32 bits is unlikely, then I
don't think it makes sense to store those same values inside of 64 bits,
either.
Of course, that means implementing overflow detection, but that's a
small price to pay for shaving off extra data from the commit-graph
file.
> Best,
> --
> Jakub Narębski
Thanks,
Taylor
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
2020-09-15 19:05 ` Jakub Narębski
2020-09-15 19:32 ` Taylor Blau
@ 2020-09-15 21:14 ` Junio C Hamano
2020-09-15 21:25 ` Jakub Narębski
1 sibling, 1 reply; 13+ messages in thread
From: Junio C Hamano @ 2020-09-15 21:14 UTC (permalink / raw)
To: Jakub Narębski; +Cc: git, Abhishek Kumar, Derrick Stolee, Taylor Blau
jnareb@gmail.com (Jakub Narębski) writes:
> Those are patches that are part of GSoC project of Shourya Shukla:
> 'Convert submodule to builtin'.
> ...
> Those are patches that are part of GSoC project of Hariom Verma:
> 'Unify ref-filter formats with other --pretty formats'
Yes and yes. What is your intention for highlighting that these two
are GSoC originated projects, by the way?
These entries in the What's cooking report will eventually be part
of the Release Notes, it is tempting to mention it there for
publicity of the GSoC program (and I happen to work for OSPO that
runs the program).
But at the same time, it becomes part of the published history
(i.e. commit log for the merge commits) and over there, I am not
sure if we want to mention GSoC---who the changes came from and in
what context is much less important than what the actual changes are
while reading the history of the project, trying to understand the
current state of the code [*1*].
> I'd like to point out that latest series of patches by Abhishek Kumar
> which are final part of 'Implement Generation Number v2' is at what I
> believe is next to final iteration:
Yup, I've been watching from the sideline and appreciate that you've
given the author quite a lot of help to make the series into a good
shape.
> Because corrected commit date offsets are not monotone, that is after
> value that doesn't fit in 32 bits (in parent) there can be one that does
> (in child). It is extremely unlikely that in real repositories there
> would be that large corrections needed, but it can happen in theory, and
> therfore we need some way to handle overflow if we choose this option.
> And of course we should test that overflow handling works correctly.
My gut feeling is that overflow handling needs there whether the
field is 32-bit or 64-bit.
Thanks.
[Footnote]
*1* Unless you want to have more cues to notice commits by less
experienced contributors and want to focus more carefully while
bisecting the history or something like that, that is.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
2020-09-15 21:14 ` Junio C Hamano
@ 2020-09-15 21:25 ` Jakub Narębski
2020-09-15 21:45 ` Junio C Hamano
0 siblings, 1 reply; 13+ messages in thread
From: Jakub Narębski @ 2020-09-15 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Abhishek Kumar, Derrick Stolee, Taylor Blau
On Tue, 15 Sep 2020 at 23:14, Junio C Hamano <gitster@pobox.com> wrote:
> jnareb@gmail.com (Jakub Narębski) writes:
>
> > Those are patches that are part of GSoC project of Shourya Shukla:
> > 'Convert submodule to builtin'.
> > ...
> > Those are patches that are part of GSoC project of Hariom Verma:
> > 'Unify ref-filter formats with other --pretty formats'
>
> Yes and yes. What is your intention for highlighting that these two
> are GSoC originated projects, by the way?
It was to compare the final status (merged vs not merged) of all Git's
GSoC 2020 projects... in a bit clumsy way, I admit.
[...]
> > Because corrected commit date offsets are not monotone, that is after
> > value that doesn't fit in 32 bits (in parent) there can be one that does
> > (in child). It is extremely unlikely that in real repositories there
> > would be that large corrections needed, but it can happen in theory, and
> > therefore we need some way to handle overflow if we choose this option.
> > And of course we should test that overflow handling works correctly.
>
> My gut feeling is that overflow handling needs to be there whether the
> field is 32-bit or 64-bit.
Not if the size on-disk is the same as the size in memory:
timestamp_t is usually 64 bit (and even unsigned 64 bit epoch
would be enough - its range is over twenty times the present
age of the universe per direction).
Best,
--
Jakub Narębski
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
2020-09-15 21:25 ` Jakub Narębski
@ 2020-09-15 21:45 ` Junio C Hamano
2020-09-15 21:48 ` Taylor Blau
2020-09-15 22:02 ` Jakub Narębski
0 siblings, 2 replies; 13+ messages in thread
From: Junio C Hamano @ 2020-09-15 21:45 UTC (permalink / raw)
To: Jakub Narębski; +Cc: git, Abhishek Kumar, Derrick Stolee, Taylor Blau
Jakub Narębski <jnareb@gmail.com> writes:
>> My gut feeling is that overflow handling needs to be there whether the
>> field is 32-bit or 64-bit.
>
> Not if the size on-disk is the same as the size in memory:
> timestamp_t is usually 64 bit (and even unsigned 64 bit epoch
> would be enough - its range is over twenty times the present
> age of the universe per direction).
Yes, and "corrected commit dates" is about accommodating commits
with absurd out-of-sync timestamp mixed in a history with commits
with correct timestamp, right? What happens if the absurd timestamp
is near the limit of the range? You do not have to live through the
end of the universe---you only have to create a commit object that
records such a timestamp, no?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
2020-09-15 21:45 ` Junio C Hamano
@ 2020-09-15 21:48 ` Taylor Blau
2020-09-15 22:32 ` Junio C Hamano
2020-09-15 22:02 ` Jakub Narębski
1 sibling, 1 reply; 13+ messages in thread
From: Taylor Blau @ 2020-09-15 21:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jakub Narębski, git, Abhishek Kumar, Derrick Stolee, Taylor Blau
On Tue, Sep 15, 2020 at 02:45:51PM -0700, Junio C Hamano wrote:
> Jakub Narębski <jnareb@gmail.com> writes:
>
>
> >> My gut feeling is that overflow handling needs to be there whether the
> >> field is 32-bit or 64-bit.
> >
> > Not if the size on-disk is the same as the size in memory:
> > timestamp_t is usually 64 bit (and even unsigned 64 bit epoch
> > would be enough - its range is over twenty times the present
> > age of the universe per direction).
>
> Yes, and "corrected commit dates" is about accommodating commits
> with absurd out-of-sync timestamp mixed in a history with commits
> with correct timestamp, right? What happens if the absurd timestamp
> is near the limit of the range? You do not have to live through the
> end of the universe---you only have to create a commit object that
> records such a timestamp, no?
I completely agree with Junio's sentiment here. The overflow handling
needs to exist no matter what, but let's remember what's common and what
isn't.
Since it's not common to be towards the end of even just the 32-bit
range, let's "optimize" for that and store the fields as 32 bits wide.
Thanks,
Taylor
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
2020-09-15 21:45 ` Junio C Hamano
2020-09-15 21:48 ` Taylor Blau
@ 2020-09-15 22:02 ` Jakub Narębski
1 sibling, 0 replies; 13+ messages in thread
From: Jakub Narębski @ 2020-09-15 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Abhishek Kumar, Derrick Stolee, Taylor Blau
On Tue, 15 Sep 2020 at 23:45, Junio C Hamano <gitster@pobox.com> wrote:
>
> Jakub Narębski <jnareb@gmail.com> writes:
>
>
> >> My gut feeling is that overflow handling needs to be there whether the
> >> field is 32-bit or 64-bit.
> >
> > Not if the size on-disk is the same as the size in memory:
> > timestamp_t is usually 64 bit (and even unsigned 64 bit epoch
> > would be enough - its range is over twenty times the present
> > age of the universe per direction).
>
> Yes, and "corrected commit dates" is about accommodating commits
> with absurd out-of-sync timestamp mixed in a history with commits
> with correct timestamp, right? What happens if the absurd timestamp
> is near the limit of the range? You do not have to live through the
> end of the universe---you only have to create a commit object that
> records such a timestamp, no?
Well, as Git stores dates using timestamp_t type, it wouldn't
be able to handle such commit dates anyway. Also, commit-graph
format has only 34 bits reserved for storing commit dates anyway
(32 + 2 bits, with 30 bits of the other byte used for topological
levels aka generation number v1).
As parse_timestamp is strtoumax, having textual representation
of timestamp not fit in 64 bits results in a range error (errno,
which we do not check, is set to ERANGE) and UINTMAX_MAX
is returned.
Best,
--
Jakub Narębski
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
2020-09-15 21:48 ` Taylor Blau
@ 2020-09-15 22:32 ` Junio C Hamano
0 siblings, 0 replies; 13+ messages in thread
From: Junio C Hamano @ 2020-09-15 22:32 UTC (permalink / raw)
To: Taylor Blau; +Cc: Jakub Narębski, git, Abhishek Kumar, Derrick Stolee
Taylor Blau <me@ttaylorr.com> writes:
> I completely agree with Junio's sentiment here. The overflow handling
> needs to exist no matter what, but let's remember what's common and what
> isn't.
>
> Since it's not common to be towards the end of even just the 32-bit
> range, let's "optimize" for that and store the fields as 32 bits wide.
Thanks. I realize I wasn't clear but that is what I meant. If we
need to deal with overflowing situation sensibly anyway, there may
not be much advantage in using 64-bit until year 2038.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
2020-09-10 4:52 ` Junio C Hamano
@ 2020-09-15 22:48 ` Eric Sunshine
2020-09-15 22:54 ` Junio C Hamano
0 siblings, 1 reply; 13+ messages in thread
From: Eric Sunshine @ 2020-09-15 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
On Thu, Sep 10, 2020 at 12:52 AM Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> > "git worktree add" learns "-d" as short for "--detach".
>
> Thanks.
Since this thread is active again, I guess I'll nudge this a bit. The
es/wt-add-detach topic still seems to need the above tweak to prevent
it from being inaccurate[1]. (At least I don't see the updated merge
message in 'seen' yet.) Thanks.
[1]: https://lore.kernel.org/git/CAPig+cQnnukVoJTgsu1sGFWkAYv7V38-0s-CgYuMyizYHhSFQQ@mail.gmail.com/
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
2020-09-15 22:48 ` Eric Sunshine
@ 2020-09-15 22:54 ` Junio C Hamano
0 siblings, 0 replies; 13+ messages in thread
From: Junio C Hamano @ 2020-09-15 22:54 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Git List
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Thu, Sep 10, 2020 at 12:52 AM Junio C Hamano <gitster@pobox.com> wrote:
>> Eric Sunshine <sunshine@sunshineco.com> writes:
>> > "git worktree add" learns "-d" as short for "--detach".
>>
>> Thanks.
>
> Since this thread is active again, I guess I'll nudge this a bit. The
> es/wt-add-detach topic still seems to need the above tweak to prevent
> it from being inaccurate[1]. (At least I don't see the updated merge
> message in 'seen' yet.) Thanks.
Thanks. https://github.com/git/git/commit/698501fba3
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-09-15 22:55 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-09 22:32 What's cooking in git.git (Sep 2020, #03; Wed, 9) Junio C Hamano
2020-09-09 23:07 ` Eric Sunshine
2020-09-10 4:52 ` Junio C Hamano
2020-09-15 22:48 ` Eric Sunshine
2020-09-15 22:54 ` Junio C Hamano
2020-09-15 19:05 ` Jakub Narębski
2020-09-15 19:32 ` Taylor Blau
2020-09-15 21:14 ` Junio C Hamano
2020-09-15 21:25 ` Jakub Narębski
2020-09-15 21:45 ` Junio C Hamano
2020-09-15 21:48 ` Taylor Blau
2020-09-15 22:32 ` Junio C Hamano
2020-09-15 22:02 ` Jakub Narębski
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 NNTP newsgroup(s).