git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
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 :)

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