From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org, me@ttaylorr.com
Subject: Re: [PATCH v3] revision: add `--ignore-missing-links` user option
Date: Tue, 19 Sep 2023 08:13:39 -0700 [thread overview]
Message-ID: <xmqqfs3ai4bg.fsf@gitster.g> (raw)
In-Reply-To: <CAOLa=ZQdtdpu3KMMpvgr16A19xtjtOXG=HAtNrLKv97-D=Cd+g@mail.gmail.com> (Karthik Nayak's message of "Tue, 19 Sep 2023 10:45:37 +0200")
Karthik Nayak <karthik.188@gmail.com> writes:
> If I remove the hardcoding, it would mean that
> `--ignore-missing-links` would skip missing commits but for
> non-commits objects, the user would have to pass
> `--missing=allow-any` else rev-list would still error out with a
> missing object error.
>
> Don't you think this would be confusing for the user? I'm happy
> to send a revised version removing this hardcoding if you still
> think otherwise :)
Yes. This is an example of flexibility and ergonomics at odds, and
for a low-level plumbing like rev-list, I would prefer not to limit
the flexibility unnecessarily.
I do not care about the ability to pass allow-any here. But when
you traverse a range A..B with the --ignore-missing-links option,
the reporting mechanism based on the --boundary cannot tell which
ones are at the usual "traversal boundaries" and which ones are ones
beyond the broken links, can it? If you allowed the users to pass
'print', then those reported with '?' prefix would be the missing
ones. The ones that are reported with '-' prefix may still be
mixture of the two kinds, but you can now subtract one set from the
other set to see which ones are true boundaries and which ones are
missing. The hardcoded "we do not let __ma() logic to kick in"
makes it impossible, which is what I find disturbing.
Thanks.
next prev parent reply other threads:[~2023-09-19 15:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-08 17:42 [PATCH] revision: add `--ignore-missing-links` user option Karthik Nayak
2023-09-08 19:19 ` Junio C Hamano
2023-09-12 14:42 ` Karthik Nayak
2023-09-12 15:58 ` [PATCH v2] " Karthik Nayak
2023-09-12 17:07 ` Taylor Blau
2023-09-13 9:32 ` Karthik Nayak
2023-09-13 17:17 ` Taylor Blau
2023-09-15 8:34 ` [PATCH v3] " Karthik Nayak
2023-09-15 18:54 ` Junio C Hamano
2023-09-18 10:12 ` Karthik Nayak
2023-09-18 15:56 ` Junio C Hamano
2023-09-19 8:45 ` Karthik Nayak
2023-09-19 15:13 ` Junio C Hamano [this message]
2023-09-20 10:45 ` [PATCH v4] " Karthik Nayak
2023-09-20 15:32 ` Junio C Hamano
2023-09-21 10:53 ` Karthik Nayak
2023-09-21 19:16 ` Junio C Hamano
2023-09-24 16:14 ` Karthik Nayak
2023-09-25 16:57 ` Junio C Hamano
2023-09-27 16:26 ` 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=xmqqfs3ai4bg.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.com \
--cc=me@ttaylorr.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).