git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Toon Claes <toon@iotcl.com>
Cc: Karthik Nayak <karthik.188@gmail.com>,
	 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: Wed, 19 Feb 2025 09:04:19 -0800	[thread overview]
Message-ID: <xmqqwmdlg92k.fsf@gitster.g> (raw)
In-Reply-To: <87a5aiqmeq.fsf@iotcl.com> (Toon Claes's message of "Wed, 19 Feb 2025 11:06:05 +0100")

Toon Claes <toon@iotcl.com> writes:

> So can I suggest to name the option `--no-reflog`? To me that makes it
> more obvious the reflog won't exist no more after migrating, and is more
> in line with the common UX of Git. Also emphasizing this more clearly in
> the commit message and help message also would be advised.

I have always thought, until I saw the message I am responding to,
that everybody would expect that "migrate --skip=X --skip=Y" that
usually migrates X and Y and Z would lose X and Y with the
transition.  But I realized that it was most likely because I happen
to know that the choice between reftable and files backends is
"which one do you take, you cannot have both at the same time", and
it was clear that "skip and keep using the old form" is not on the
table.  For all others, your interpretation of the option name is
entirely plausible.  So I agree `--no-reflog` is really an excellent
suggestion, even though `--reflog` option would be a no-op, and
`--no-refs` would be a "Huh?" option that only logically makes sense
to have for completeness but nobody would want to use ;-)





  reply	other threads:[~2025-02-19 17:04 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
2025-02-14  8:50           ` Karthik Nayak
2025-02-19 10:06     ` Toon Claes
2025-02-19 17:04       ` Junio C Hamano [this message]
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=xmqqwmdlg92k.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 \
    --cc=toon@iotcl.com \
    /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).