The idea is to allow callers to redirect log-tree's output to a file without having to freopen() stdout (which would modify global state, a big no-no-no for library functions).
I reviewed log-tree.c, graph.c, line-log.c, builtin/shortlog.c and builtin/log.c line by line to ensure that all calls that assumed stdout previously now use the `file` field instead, of course. I would welcome additional eyes to go over the code to confirm that I did not miss anything. This patch series ends up removing the freopen() call in the format-patch command, but that is only a by-product. The ulterior motive behind this series is to allow the sequencer to write a `patch` file as part of my endeavor to move large chunks of rebase -i into a builtin. Speaking of said endeavor: it is going a lot slower than I would like, but I really need rebase -i to be robust. To that end, I not only review and re-review my patches frequently, I also use a cross-validation technique inspired by my original ll-merge validation as well as GitHub's Scientist library: I taught rebase -i to run every interactive rebase twice, once with the original shell script's code, and once with the builtin rebase--helper, and then to verify that the end result is as similar as can be expected (the commit dates will differ most of the time, of course). It is a bit tedious, of course, because I have to resolve every merge conflict twice, I have to reword everything twice (identically!), and I have to wait longer for the rebase to finish. It is worth it, though, because I really need rebase -i to be robust, as it is the center piece of almost all of my workflows. I organized the patch series into a thicket of branches, to make it easier to review them; In addition to this here patch series, I plan to submit 11 separate, partially interdependent series, resubmit another one, and I already submitted a couple of patches earlier that were integrated or replaced by superior solutions (thanks, Peff!). Skipping the temporary patches (e.g. for cross-validation), that leaves me with 99 patches to submit in total (sing with me: "99 patches of code to submit, 99 patches of code, ..."). I was curious just how much these patches could accelerate rebase -i, so I disabled the cross-validation temprarily and let Travis measure the performance improvements via the t/perf test that was already merged to `master`. Look for "3404.2" in this build's logs: https://travis-ci.org/git/git/builds/138277774 It looks like a 3x speedup on Linux, a 4x speedup on MacOSX and my local measurements suggest a >5x speed-up on Windows. Johannes Schindelin (5): log-tree: respect diffopt's configured output file stream line-log: respect diffopt's configured output file stream graph: respect the diffopt.file setting shortlog: support outputting to streams other than stdout format-patch: avoid freopen() builtin/log.c | 71 +++++++++++++++++++++++++++--------------------------- builtin/shortlog.c | 13 ++++++---- graph.c | 30 +++++++++++++---------- line-log.c | 34 +++++++++++++------------- log-tree.c | 65 +++++++++++++++++++++++++------------------------ shortlog.h | 1 + 6 files changed, 111 insertions(+), 103 deletions(-) Published-As: https://github.com/dscho/git/releases/tag/diffopt.file-v1 -- 2.9.0.118.gce770ba.dirty base-commit: 05219a1276341e72d8082d76b7f5ed394b7437a4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
