git@vger.kernel.org mailing list mirror (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>,
	Takuto Ikuta <tikuta@chromium.org>,
	git@jeffhostetler.com, Derrick Stolee <dstolee@microsoft.com>,
	Ben Peart <benpeart@microsoft.com>
Subject: Re: What's cooking in git.git (Mar 2018, #03; Wed, 14)
Date: Thu, 15 Mar 2018 09:36:22 +0100	[thread overview]
Message-ID: <87r2olenw9.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <xmqqefkm6s06.fsf@gitster-ct.c.googlers.com>


On Thu, Mar 15 2018, Junio C. Hamano jotted:

> * ti/fetch-everything-local-optim (2018-03-14) 1 commit
>  - fetch-pack.c: use oidset to check existence of loose object

Looks good to me, and great to have such an optimization in.

> * ab/pcre-v2 (2018-03-14) 3 commits
>
>  Will merge to 'next'.
>
>[...]
>
> * ab/perl-fixes (2018-03-05) 13 commits
>
>  Will merge to 'master'.

Given 2.17-rc1 next Tuesday according to your calendar, what's the
status of these two landing in 2.17?

I'd like to annoy packagers with all this perl/ stuff in just one
release instead of spreading out out over two, and without ab/perl-fixes
they'll need another hack to avoid installing our Error.pm.

The ab/pcre-v2 is less important, but given the minimal nature of it
would be very nice to have in 2.17 as well so we get off the
mostly-unmaintained v1 sooner than later.

> * nd/repack-keep-pack (2018-03-07) 6 commits
>  - SQUASH???
>  - pack-objects: display progress in get_object_details()
>  - pack-objects: show some progress when counting kept objects
>  - gc --auto: exclude base pack if not enough mem to "repack -ad"
>  - repack: add --keep-pack option
>  - t7700: have closing quote of a test at the beginning of line
>
>  "git gc" in a large repository takes a lot of time as it considers
>  to repack all objects into one pack by default.  The command has
>  been taught to pretend as if the largest existing packfile is
>  marked with ".keep" so that it is left untouched while objects in
>  other packs and loose ones are repacked.
>
>  Expecting a reroll.
>  cf. <CACsJy8BW_EtxQvgL=YrCXCQY7cEWCQxgfkeH=Gd=X=uVYhPJcw@mail.gmail.com>
>  Except for final finishing touches, this looked more-or-less ready
>  for 'next'.
>
>

As I noted in 87a7vdqegi.fsf@evledraar.gmail.com and
877eqhq7ha.fsf@evledraar.gmail.com (both at:
https://public-inbox.org/git/?q=87a7vdqegi.fsf%40evledraar.gmail.com) I
think we should change the too-specific behavior here to be more generic
(and am happy to do the work pending feedback from Duy on what he thinks
about it).

I'm also interested to know from those at Microsoft (CC'd some) if the
mechanism I've proposed is something closer to what they could
eventually use to gc windows.git.

I know that now it doesn't GC now, and they have some side-channel
mechanism for pre-deploying large (daily?) packs to clients, if it's
adjusted as I suggest gc could be told not to touch packs of that size,
leaving only stray small packs from "git pull" and loose objects to GC.

I may also have entirely misunderstood how it works, this is from brief
in-person conversations at Git Merge.

But as far as mainlining some of that eventually I think it would be
good to get feedback on whether the mechanism I proposed would get in
their way more or less than what Duy has, or be entirely irrelevant
because they need something else.

Thanks!

  parent reply	other threads:[~2018-03-15  8:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15  1:34 What's cooking in git.git (Mar 2018, #03; Wed, 14) Junio C Hamano
2018-03-15  6:30 ` Duy Nguyen
2018-03-15 16:54   ` Junio C Hamano
2018-03-15  8:36 ` Ævar Arnfjörð Bjarmason [this message]
2018-03-15 17:33   ` Junio C Hamano
2018-03-19 21:16   ` Derrick Stolee
2018-03-15 19:18 ` Lars Schneider
2018-03-15 23:00   ` Lars Schneider
2018-03-16  0:54   ` Junio C Hamano
2018-03-16 21:31 ` Jonathan Tan
2018-03-16 21:52   ` Junio C Hamano
2018-03-16 22:08     ` Jonathan Nieder
2018-03-17  0:53       ` Junio C Hamano

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=87r2olenw9.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=benpeart@microsoft.com \
    --cc=dstolee@microsoft.com \
    --cc=git@jeffhostetler.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    --cc=tikuta@chromium.org \
    /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).