Re: What's cooking in git.git (Apr 2019, #03; Tue, 16)

["Ævar Arnfjörð Bjarmason" <avarab@gmail.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 :)