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

From: Christian Couder <christian.couder@gmail.com>
Date: Jun 10, 2016, 08:59 UTC
Message-ID: <CAP8UFD1zSAxyHfZgBbfoF=th0waZWEhvHP+4jUxxVO+rU9N9RA@mail.gmail.com>
In-Reply-To: <alpine.DEB.2.20.1606100852550.3039@virtualbox>

Hi Dscho,

On Fri, Jun 10, 2016 at 9:01 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 25 quoted lines

> Hi Hannes,
>
> 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/

> 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

Thanks for testing, Christian.