From: Junio C Hamano <gitster@pobox.com>
To: "Martin Ågren" <martin.agren@gmail.com>
Cc: ks1322 ks1322 <ks1322@gmail.com>,
git@vger.kernel.org, Victoria Dye <vdye@github.com>
Subject: Re: [PATCH] diagnose: require repository
Date: Sat, 14 Oct 2023 10:15:19 -0700 [thread overview]
Message-ID: <xmqq5y39unvc.fsf@gitster.g> (raw)
In-Reply-To: <20231014135302.13095-1-martin.agren@gmail.com> ("Martin Ågren"'s message of "Sat, 14 Oct 2023 15:53:01 +0200")
Martin Ågren <martin.agren@gmail.com> writes:
> When `git diagnose` is run from outside a repo, it begins collecting
> various information before eventually hitting a segmentation fault,
> leaving an incomplete zip file behind.
>
> Switch from the gentle setup to requiring a git directory. Without a git
> repo, there isn't really much to diagnose.
>
> We could possibly do a best-effort collection of information about the
> machine and then give up. That would roughly be today's behavior but
> with a controlled exit rather than a segfault. However, the purpose of
> this tool is largely to create a zip archive. Rather than creating an
> empty zip file or no zip file at all, and having to explain that
> behavior, it seems more helpful to bail out clearly and early with a
> succinct error message.
Without having thought things through, offhand I agree with your "no
repository? there is nothing worth tarring up then" assessment.
Because "git bugreport --diag" unconditionally spawns "git
diagnose", the former may also want to be extra careful, perhaps
like the attached patch.
builtin/bugreport.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git c/builtin/bugreport.c w/builtin/bugreport.c
index d2ae5c305d..ac9e05fcf7 100644
--- c/builtin/bugreport.c
+++ w/builtin/bugreport.c
@@ -146,6 +146,11 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
report_path.buf);
}
+ if (!startup_info->have_repository && diagnose != DIAGNOSE_NONE) {
+ warning(_("no repository--diagnostic output disabled"));
+ diagnose = DIAGNOSE_NONE;
+ }
+
/* Prepare diagnostics, if requested */
if (diagnose != DIAGNOSE_NONE) {
struct strbuf zip_path = STRBUF_INIT;
next prev parent reply other threads:[~2023-10-14 17:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-14 11:59 Bug: git diagnose crashes with Segmentation fault outside of git repository ks1322 ks1322
2023-10-14 13:53 ` [PATCH] diagnose: require repository Martin Ågren
2023-10-14 14:56 ` Kristoffer Haugsbakk
2023-10-14 17:15 ` Junio C Hamano [this message]
2023-10-19 13:18 ` Martin Ågren
2023-10-19 18:09 ` Junio C Hamano
2023-10-19 18:16 ` Victoria Dye
2023-10-14 17:22 ` Bug: git diagnose crashes with Segmentation fault outside of git repository Christian Couder
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=xmqq5y39unvc.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ks1322@gmail.com \
--cc=martin.agren@gmail.com \
--cc=vdye@github.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 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.