From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Duy Nguyen <pclouds@gmail.com>,
Phillip Wood <phillip.wood@dunelm.org.uk>,
Derrick Stolee <dstolee@microsoft.com>, Eric Wong <e@80x24.org>
Subject: Re: What's cooking in git.git (Apr 2019, #03; Tue, 16)
Date: Tue, 16 Apr 2019 16:51:14 +0200 [thread overview]
Message-ID: <87d0lmatr1.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <xmqqef62ozny.fsf@gitster-ct.c.googlers.com>
On Tue, Apr 16 2019, Junio C Hamano wrote:
> * jc/gettext-test-fix (2019-04-15) 1 commit
> - gettext tests: export the restored GIT_TEST_GETTEXT_POISON
>
> The GETTEXT_POISON test option has been quite broken ever since it
> was made runtime-tunable, which has been fixed.
>
> Will merge to 'next'.
LGTM, but AFAICT this patch of yours never got sent to the list,
oversight?
> * ds/midx-expire-repack (2019-01-27) 10 commits
> - midx: add test that 'expire' respects .keep files
> - multi-pack-index: test expire while adding packs
> - midx: implement midx_repack()
> - multi-pack-index: prepare 'repack' subcommand
> - multi-pack-index: implement 'expire' subcommand
> - midx: refactor permutation logic and pack sorting
> - midx: simplify computation of pack name lengths
> - multi-pack-index: prepare for 'expire' subcommand
> - Docs: rearrange subcommands for multi-pack-index
> - repack: refactor pack deletion for future use
>
> "git multi-pack-index expire/repack" are new subcommands that
> consult midx file and are used to drop unused pack files and
> coalesce small pack files that are still in use.
>
> Comments?
I have not used this myself, but skimmed the patches. My 0.02: Seems
safe to integrate since it's fairly well-tested at MSFT & off by
default.
> * ew/repack-with-bitmaps-by-default (2019-03-18) 3 commits
> - pack-objects: default to writing bitmap hash-cache
> - t5310: correctly remove bitmaps for jgit test
> - repack: enable bitmaps by default on bare repos
>
> The connectivity bitmaps are created by default in bare
> repositories now; also the pathname hash-cache is created by
> default to avoid making crappy deltas when repacking.
>
> Will merge to 'next'.
Pushing *from* a bare repo isn't going to be super common (although
stuff like server->server replication...). The case I reported in
https://public-inbox.org/git/87zhoz8b9o.fsf@evledraar.gmail.com/ will
result in some users seeing a huge slowdown due to this in some
cases.
I'm inclined to hold that sort of thing off until we get that sorted out
/ perf tested. It taking ~2m instead of ~500ms sucks pretty badly (in my
test-case).
> * ab/gc-docs (2019-04-08) 11 commits
> - gc docs: remove incorrect reference to gc.auto=0
> - gc docs: clarify that "gc" doesn't throw away referenced objects
> - gc docs: note "gc --aggressive" in "fast-import"
> - gc docs: downplay the usefulness of --aggressive
> - gc docs: note how --aggressive impacts --window & --depth
> - gc docs: fix formatting for "gc.writeCommitGraph"
> - gc docs: re-flow the "gc.*" section in "config"
> - gc docs: include the "gc.*" section from "config" in "gc"
> - gc docs: clean grammar for "gc.bigPackThreshold"
> - gc docs: stop noting "repack" flags
> - gc docs: modernize the advice for manually running "gc"
>
> Update docs around "gc".
>
> Will merge to 'next'.
Any chance on making that s/next/master/ sooner than later?
It's just doc changes so I think the usual "let's cook in next..." has
less value, and I have some follow-ups I'd like to submit sooner than
later without me/you dealing with conflicts.
If not, no problem :)
> * nd/precious (2019-04-09) 1 commit
> - Introduce "precious" file concept
>
> "git clean" learned to pay attention to the 'precious' attributes
> and keep untracked paths with the attribute instead of removing
> when the "--keep-precious" is given.
>
> Will merge to 'next'.
Duy had a message about this in
https://public-inbox.org/git/CACsJy8AEZ-Lz6zgEsuNukvphB9TTa9FAC1gK05fhnie2xtfc9w@mail.gmail.com/
If that was just a "I don't have time to deal with Ævar's deluge of
comments" (sorry!) I'm happy to re-roll with the nits I had if anyone
thinks those make sense (doc & test adjustments...).
But that note is terse, not sure if it means "let's drop this no matter
what" (for reasons...), ..., Duy?
> * nd/diff-parseopt-4 (2019-03-24) 20 commits
> [...]
> + diff-parseopt: convert --[no-]abbrev
> [...]
> Will merge to 'master'.
Have some stuff I meant to re-roll conflicting with this, will be good
to have it in master.
> * pw/rebase-i-internal-rfc (2019-03-21) 12 commits
> - rebase -i: run without forking rebase--interactive
> - rebase: use a common action enum
> - rebase -i: use struct rebase_options in do_interactive_rebase()
> - rebase -i: use struct rebase_options to parse args
> - rebase -i: use struct object_id for squash_onto
> - rebase -i: use struct commit when parsing options
> - rebase -i: remove duplication
> - rebase -i: combine rebase--interactive.c with rebase.c
> - rebase: use OPT_RERERE_AUTOUPDATE()
> - rebase: rename write_basic_state()
> - sequencer: always discard index after checkout
> - Merge branch 'ag/sequencer-reduce-rewriting-todo' into pw/rebase-i-internal-rfc
> (this branch uses ag/sequencer-reduce-rewriting-todo.)
>
> The internal implementation of "git rebase -i" has been updated to
> avoid forking a separate "rebase--interactive" process.
>
> Comments? Is this ready?
I gave this some stress testing/review in your infra, works for me so
far, and a good performance improvement.
My only problem with it is that the commit message doesn't note just
quite how awesome it is, but I can live with that :)
next prev parent reply other threads:[~2019-04-16 14:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-16 13:19 What's cooking in git.git (Apr 2019, #03; Tue, 16) Junio C Hamano
2019-04-16 14:51 ` Ævar Arnfjörð Bjarmason [this message]
2019-04-16 15:26 ` Junio C Hamano
2019-04-17 7:18 ` Ævar Arnfjörð Bjarmason
2019-04-18 0:12 ` Junio C Hamano
2019-04-17 9:33 ` Duy Nguyen
2019-04-17 9:52 ` Phillip Wood
2019-04-17 10:22 ` Ævar Arnfjörð Bjarmason
2019-04-16 15:27 ` Ben Peart
2019-04-17 2:37 ` Junio C Hamano
2019-04-16 16:25 ` Stalled ds/ branches (was What's cooking in git.git (Apr 2019, #03; Tue, 16)) Derrick Stolee
2019-04-16 17:32 ` jt/clone-server-option " Jonathan Tan
2019-04-17 2:39 ` Junio C Hamano
2019-04-17 16:18 ` Jonathan Tan
2019-04-18 1:51 ` Junio C Hamano
2019-04-17 2:37 ` What's cooking in git.git (Apr 2019, #03; Tue, 16) Taylor Blau
2019-04-17 5:38 ` Junio C Hamano
2019-04-17 5:42 ` Taylor Blau
2019-04-17 6:14 ` Junio C Hamano
2019-04-18 6:54 ` Taylor Blau
2019-04-17 12:50 ` jc/format-patch-error-check, was " Johannes Schindelin
2019-04-18 0:48 ` Junio C Hamano
2019-04-17 12:52 ` ab/test-lib-pass-trace2-env, " Johannes Schindelin
2019-04-18 0:19 ` Denton Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d0lmatr1.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=dstolee@microsoft.com \
--cc=e@80x24.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).