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
