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

From: Emily Shaffer <[email-masked]>
Date: Thu, 19 Mar 2020 14:39:02 -0700

On Wed, Mar 04, 2020 at 10:35:04PM +0100, Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 2 Mar 2020, Emily Shaffer wrote:
> 
> >  .gitignore                      |   1 +
> >  Documentation/git-bugreport.txt |  46 ++++++++++++++
> >  Makefile                        |   5 ++
> >  bugreport.c                     | 105 ++++++++++++++++++++++++++++++++
> >  command-list.txt                |   1 +
> >  strbuf.c                        |   4 ++
> >  strbuf.h                        |   1 +
> >  t/t0091-bugreport.sh            |  61 +++++++++++++++++++
> >  8 files changed, 224 insertions(+)
> >  create mode 100644 Documentation/git-bugreport.txt
> >  create mode 100644 bugreport.c
> >  create mode 100755 t/t0091-bugreport.sh
> 
> Hmm. I am still _quite_ convinced that this would be much better as a
> built-in. Remember, non-built-ins come with a footprint, and I do not
> necessarily think that you will want to spend 3MB on a `git-bugreport`
> executable when you could have it for a couple dozen kilobytes inside
> `git` instead.

This is the kind of stuff I really wanted to get straightened out by
sending the smaller changeset, so I'm glad to be having this
conversation (again, and hopefully for the last time). I read the
replies to this mail, which I'm truncating as I think many of them are
distracting rather than discussion-worthy, and have tried to summarize:

Builtin:
+ Don't have to call out-of-process to identify 'git version --build-options'
+ Better assurance that we aren't shipping a broken bugreport alongside a new
  version
- Binary bloat, possible startup time hit
? Libraries will behave identically to where the user is seeing issues
  (This point is a possible pro but also a possible con; see similar point in
  standalone list)

Standalone:
+ Could investigate libraries who aren't behaving the way they should.
  (This seems like it'd be better addressed by regression tests, and if we're so
  sure that git-bugreport is working with the info at hand correctly, why don't
  we just write the git binary that way too?)
+ Avoid binary bloat in the main executable.
- Have to ship a big standalone binary instead.
- To get accurate version/build info, need to query the Git executable in a new
  process

Of course if I missed capturing something, please add/correct. Some of
these concerns are quantifiable - binary size and overhead, for example
- so I'm planning on doing some experiments in the coming days. I plan
put together the handful of patches in the latest version of the topic
in both standalone and builtin mode, and then gather the following info:

 - Binary size of 'git'
 - Binary size of 'git-bugreport' when applicable
 - Time for "make" following clean
 - Time for 'git status' on an identical real-world repo (I'll use ours,
   without touching the repo state e.g. changing branch or fetching in
   between)
 - Time to editor for 'git bugreport' with the same setup as previous
 - Peak memory footprint during 'git status'

And of course, if there's more to compare that I can quantify, please
let me know that too. I expect I'll be ready to run the experiments by
Monday (taking some time off tomorrow) so there's time for me to hear
about other concerns.

I'll hold off on sharing my own preference until after we've got some
benchmarking to look at, so I can understand the whole picture.

 - Emily