From: Jeff Hostetler Date: Fri, 06 Mar 2020 18:58:02 GMT Subject: Re: [PATCH v9 2/5] bugreport: add tool to generate debugging info Message-ID: In-Reply-To: On 3/6/2020 1:08 PM, Junio C Hamano wrote: > Jeff Hostetler writes: > >> Having this command be a stand-alone exe rather than a builtin allows >> it to have a different linkage. For example, you could include the >> libcurl and other libraries that are only linked into the transports. >> And then report version numbers for them if you wanted. > > I actually do not think that is a good rationale. Unless your > version of "git bugreport" links into the same binary as the > "transports", it still is possible that the version of cURL (for > example) "git bugreport" can learn internally from may not have > anything to do with the version of the library used by the > transports. > > Of course, making "bugreport" a built-in, i.e. the same binary as > the non-transport part of Git, is not a solution for that issue, > either. As Dscho suggested and recent rounds of "git bugreport" > implements, teaching the transport binaries an option to report > relevant pieces of information regarding the libraries they use, and > making "git bugreport" ask them, is a very good solution for that. > > What makes it possible by making "git bugreport" stand-alone is for > it to link with libraries that the remainder of Git, including the > transports that link with libcurl, has no business linking with (a > library to obtain system details for diagnostic purposes, for > example). Early versions of "git bugreport" may not link with > anything special, but making sure it starts and stays standalone > leaves it easier to do so _without_ having to worry about splitting > the code that started as a built-in out to make it independent later. > > Yeah, that makes sense. Thanks Jeff