Hi Christian, On Fri, 10 Jun 2016, Christian Couder wrote: > On Fri, Jun 10, 2016 at 9:01 AM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > > On Thu, 9 Jun 2016, Johannes Sixt wrote: > > > >> Meanwhile, I have retrained my muscle memory to stop before typing "-i" after > >> "rebase" for an opportunity to consider whether bare rebase can be used. > >> > >> What should I say? I am impressed. It's like 100 times faster than rebase -i > >> (on Windows). I'm now using it whenever I can, and more often than not I plan > >> my rebase workflow so that I can go ahead without -i. > > > > That only means that I have to finalize my rebase--helper work (which I am > > busy doing, I am at the valgrind stage). > > > > I wonder whether that "100x" is a reliable number? ;-) FWIW I can measure > > something like a 4x speedup of the interactive rebase on Windows when > > running with the rebase--helper, and it is still noticably faster in my > > Linux VM, too. > > > >> Can't wait to test a re-roll on top of cc/apply-introduce-state! > > > > I lost track in the meantime: were those issues with unclosed file handles > > and unreleased memory in the error code paths addressed systematically? My > > mail about that seems to have been left unanswered, almost as if my > > concerns had been hand-waved away... > > Haven't I answered to your email in this thread: > > http://thread.gmane.org/gmane.comp.version-control.git/292403/ > > ? Not really. The reply (which I had not quite connected with my mail because they were over a week apart) says this: > I fixed this by moving the "close(fd)" call just after the > "apply_patch()" call. and this: > I will have another look at the 2 other places where there are > open()/close() or fopen()/fclose() calls. but nothing about a careful, systematic investigation of all error code paths. As a consequence, I fully expect to encounter test failures as soon as I test your patch series again, simply because resources are still in use when they should no longer be used. In other words, my expectations are now lower than they have been before, my concerns are not at all addressed. > > If those issues have indeed been addressed properly, and a public > > repository reliably has the newest iteration of that patch series in a > > branch without a versioned name, I will be happy to test it in Git for > > Windows' SDK again. > > This is the newest iteration: > > https://github.com/chriscool/git/commits/libify-apply-use-in-am65 And that cute 65 in the name is the revision. Ciao, Johannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html