Re: [PATCH v9 2/5] bugreport: add tool to generate debugging info

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 6, 2020, 18:25 UTC
Message-ID: <xmqqmu8t2ved.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <nycvar.QRO.7.76.6.2003061453260.46@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> If we want `bugreport` to be a first-class citizen, we should
> treat it as such.  That entails making it a built-in.

The question is, for "bugreport", if it is better to be standalone or to be built-in, and I do not think 'first-class' has anything to do with the question. The transport based on curl-library are separate binaries but they are of course first-class citizens.

Pushing and fetching will happen a lot less often than local operations like "add", "commit", "show", and not paying start-up latencies to load code and link libraries that are not necessary for local operations in built-in, while paying the cost of having to duplicate the memory and disk footprint necessary for libgit.a stuff by making the transport binaries separate from the built-ins, was conscious implementation decision we made earlier to prioritize the reduction of overhead of subcommands for local operation. Yes, the decision de-prioritizes the transport, but that does not mean they are not first-class citizens. It just means that the start-up latency for them (e.g. linking with libcurl) is not huge burden for the overall time cost for the network transfer, and it is necessary cost for them to perform what they need to do anyway, while it is something subcommands for local operations should not have to pay.

> That entails teaching
> `git-remote-https` (and potentially other non-builtins) to sprout that
> option to enquire other information that should be included in the
> generated part of the bug report.

I think later rounds of "git bugreports" already did so.

As I mentioned in a separate message to JeffH, this is a good thing to do, whether "git bugreport" is a built-in or a standalone.