Re: [PATCH v2 00/94] libify apply and use lib in am

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]