From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Patrick Steinhardt <ps@pks.im>,
Han-Wen Nienhuys <hanwen@google.com>
Subject: ps/avoid-unnecessary-hook-invocation-with-packed-refs (was: What's cooking in git.git (Feb 2022, #01; Thu, 3))
Date: Fri, 04 Feb 2022 13:31:53 +0100 [thread overview]
Message-ID: <220204.86ee4i3j5d.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <xmqqr18jnr2t.fsf@gitster.g>
On Thu, Feb 03 2022, Junio C Hamano wrote:
> * ps/avoid-unnecessary-hook-invocation-with-packed-refs (2022-01-17) 6 commits
> - refs: skip hooks when deleting uncovered packed refs
> - refs: do not execute reference-transaction hook on packing refs
> - refs: demonstrate excessive execution of the reference-transaction hook
> - refs: allow skipping the reference-transaction hook
> - refs: allow passing flags when beginning transactions
> - refs: extract packed_refs_delete_refs() to allow control of transaction
>
> Because a deletion of ref would need to remove it from both the
> loose ref store and the packed ref store, a delete-ref operation
> that logically removes one ref may end up invoking ref-transaction
> hook twice, which has been corrected.
>
> Will merge to 'next'?
> source: <cover.1642406989.git.ps@pks.im>
I think so, I didn't reply but I consider the feedback I had on it fully
addressed. In particular the "is this the right direction?" comment
replied to at https://lore.kernel.org/git/YeUhMPSlC%2FX6HRBF@ncase/
I'm not digging it up now, but I think Han-Wen correctly noted that we
have a "packed" backend for no particular good reason, and much of that
is die/stub functions, we should really just have a unified "the file
stuff" backend.
So from an API perspective messaging upwards about loose->packed or
whatever is as irrelevant as having a psql backend and messaging about
VACUUM, which is essentially paraphrasing what Patrick correctly points
out there.
next prev parent reply other threads:[~2022-02-04 12:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-04 5:22 What's cooking in git.git (Feb 2022, #01; Thu, 3) Junio C Hamano
2022-02-04 7:00 ` Eric Sunshine
2022-02-05 8:00 ` Junio C Hamano
2022-02-04 8:13 ` Opinions on merging questions (Was: What's cooking in git.git (Feb 2022, #01; Thu, 3)) Elijah Newren
2022-02-04 11:20 ` en/remerge-diff (was: Opinions on merging questions (Was: What's cooking in git.git (Feb 2022, #01; Thu, 3))) Ævar Arnfjörð Bjarmason
2022-02-04 16:42 ` en/remerge-diff Junio C Hamano
2022-02-06 11:41 ` Opinions on merging questions (Was: What's cooking in git.git (Feb 2022, #01; Thu, 3)) Eric Sunshine
2022-02-09 14:57 ` Derrick Stolee
2022-02-07 14:11 ` Phillip Wood
2022-02-04 11:25 ` jc/doc-log-messages (was: " Ævar Arnfjörð Bjarmason
2022-02-04 12:23 ` rj/receive-pack-abort-upon-disconnect " Ævar Arnfjörð Bjarmason
2022-02-04 12:25 ` cb/clear-quarantine-early-on-all-ref-update-errors " Ævar Arnfjörð Bjarmason
2022-02-04 16:45 ` cb/clear-quarantine-early-on-all-ref-update-errors Junio C Hamano
2022-02-04 12:29 ` ja/i18n-common-messages (was: What's cooking in git.git (Feb 2022, #01; Thu, 3)) Ævar Arnfjörð Bjarmason
2022-02-04 16:56 ` ja/i18n-common-messages Junio C Hamano
2022-02-05 12:18 ` ja/i18n-common-messages Jean-Noël AVILA
2022-02-06 8:12 ` ja/i18n-common-messages Bagas Sanjaya
2022-02-06 10:03 ` ja/i18n-common-messages Jean-Noël AVILA
2022-02-04 12:31 ` Ævar Arnfjörð Bjarmason [this message]
2022-02-04 12:36 ` ab/ambiguous-object-name (was: What's cooking in git.git (Feb 2022, #01; Thu, 3)) Ævar Arnfjörð Bjarmason
2022-02-04 13:05 ` tl/ls-tree-oid-only " Ævar Arnfjörð Bjarmason
2022-02-04 13:11 ` ab/only-single-progress-at-once " Ævar Arnfjörð Bjarmason
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=220204.86ee4i3j5d.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hanwen@google.com \
--cc=ps@pks.im \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.