From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org, ps@pks.im, jltobler@gmail.com
Subject: Re: [PATCH v3] builtin/refs: add '--skip-reflog' flag to bypass reflog migration
Date: Thu, 13 Feb 2025 10:06:17 -0800 [thread overview]
Message-ID: <xmqq4j0xpvmu.fsf@gitster.g> (raw)
In-Reply-To: <CAOLa=ZSDLNLYQ=zsoOqJW6KhcUqeDahNfhG-n9k1t0O6B40OnA@mail.gmail.com> (Karthik Nayak's message of "Thu, 13 Feb 2025 09:22:40 +0000")
Karthik Nayak <karthik.188@gmail.com> writes:
> To just get rid of reflogs from a repository, I think 'git reflog drop'
> or something similar would indeed be a better way to go about it. As you
> stated, with this patch, we could still face the issue wherein the
> administartor could re-enable reflog and we're back to square one.
Exactly.
> Why I think this patch is important, is because while there could be
> existing reflogs in a repository, if one doesn't care about _reflogs_
> there could be significant performance gains while migrating repos from
> one backend to the other, while also leaving the reflogs behind.
Sure. It could be done with a combination of "git reflog drop &&
git refs migrate" (or "git refs migrate && git reflog drop", if the
migrated-to backend performs better when it drops reflogs).
With "git refs migrate --skip-reflog" alone, we are very limited.
We can lose reflogs _only_ when we are migrating.
Doing it _during_ migration may very well be more efficient than
dropping first and then migrate (or the other way around), so I do
not have much against the "migrate --skip-reflog" existing. But I
find it backwards to add it first _before_ we have a tool that is
more generally applicable to wider situations, i.e., "reflog drop".
IOW, it feels as if we are worried about icing on the cake long
before we actually bake the cake.
next prev parent reply other threads:[~2025-02-13 18:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-07 11:57 [PATCH] builtin/refs: add '--skip-reflog' flag to bypass reflog migration Karthik Nayak
2025-02-07 15:23 ` Patrick Steinhardt
2025-02-11 6:18 ` Karthik Nayak
2025-02-07 17:45 ` Justin Tobler
2025-02-11 6:09 ` Karthik Nayak
2025-02-11 11:42 ` [PATCH v2] " Karthik Nayak
2025-02-11 12:21 ` Patrick Steinhardt
2025-02-11 17:48 ` Junio C Hamano
2025-02-12 17:43 ` Karthik Nayak
2025-02-13 9:25 ` Karthik Nayak
2025-02-12 18:38 ` [PATCH v3] " Karthik Nayak
2025-02-12 22:25 ` Junio C Hamano
2025-02-13 9:22 ` Karthik Nayak
2025-02-13 18:06 ` Junio C Hamano [this message]
2025-02-14 8:50 ` Karthik Nayak
2025-02-19 10:06 ` Toon Claes
2025-02-19 17:04 ` Junio C Hamano
2025-02-19 20:28 ` Karthik Nayak
2025-02-19 21:37 ` Junio C Hamano
2025-02-20 10:00 ` Karthik Nayak
2025-02-20 9:56 ` [PATCH v4] builtin/refs: add '--no-reflog' flag to drop reflogs Karthik Nayak
2025-02-20 15:14 ` Junio C Hamano
2025-02-21 8:44 ` Karthik Nayak
2025-02-21 10:04 ` [PATCH v5] " Karthik Nayak
2025-02-21 17:54 ` Junio C Hamano
2025-02-23 20:30 ` Karthik Nayak
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=xmqq4j0xpvmu.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jltobler@gmail.com \
--cc=karthik.188@gmail.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 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 NNTP newsgroup(s).