From: Jeff King <peff@peff•net>
To: Michael Haggerty <mhagger@alum•mit.edu>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail•com>,
"Stefan Beller" <sbeller@google•com>,
"Git Mailing List" <git@vger•kernel.org>,
"Jay Soffian" <jaysoffian@gmail•com>,
"Björn Gustavsson" <bgustavsson@gmail•com>
Subject: Re: Why is "git fetch --prune" so much slower than "git remote prune"?
Date: Thu, 19 Mar 2015 13:14:16 -0400 [thread overview]
Message-ID: <20150319171416.GB6386@peff.net> (raw)
In-Reply-To: <550AE1E4.7020407@alum.mit.edu>
On Thu, Mar 19, 2015 at 03:49:08PM +0100, Michael Haggerty wrote:
> For pruning, we can't use a ref_transaction as it is currently
> implemented because it would fail if any of the reference deletions
> failed. But in this case I think if any deletions fail, we would prefer
> to emit a warning but keep going.
>
> I'm trying to decide whether to have a separate function in the refs API
> to "delete as many of the following refs as possible", or whether to add
> a flag to ref_transaction_update() that says "try this update, but don't
> fail the transaction if it fails". The latter would probably be more
> work because we would need to invent a way to return multiple error
> messages from a single transaction.
Hmm, yeah. That is sort of antithetical to the original purpose of ref
transactions (which was atomicity). Given the way it is implemented now,
I don't think it would be too big a deal to keep a per-ref status (one
per "struct ref_upate"). But I would worry in the long run that it
makes things much harder on proposed ref backends, which otherwise can
consider a transaction an atomic unit.
OTOH, I do not think there is an abstracted way to do this _without_
the ref backend knowing about it. You cannot just do a series of
transactions; that defeats the purpose. It is a bit of a layering
violation that builtin/remote.c (which does this optimization already)
calls repack_without_refs directly.
-Peff
next prev parent reply other threads:[~2015-03-19 17:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-06 16:48 Why is "git fetch --prune" so much slower than "git remote prune"? Ævar Arnfjörð Bjarmason
2015-03-06 22:59 ` Jeff King
2015-03-19 14:49 ` Michael Haggerty
2015-03-19 17:14 ` Jeff King [this message]
2015-03-19 19:24 ` Junio C Hamano
2015-03-19 21:26 ` Jeff King
2015-03-20 4:51 ` Michael Haggerty
2015-03-20 7:04 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150319171416.GB6386@peff.net \
--to=peff@peff$(echo .)net \
--cc=avarab@gmail$(echo .)com \
--cc=bgustavsson@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jaysoffian@gmail$(echo .)com \
--cc=mhagger@alum$(echo .)mit.edu \
--cc=sbeller@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox