Hi Hannes,
On Fri, 10 Jun 2016, Johannes Sixt wrote:
> Am 10.06.2016 um 13:11 schrieb Johannes Schindelin:
> > On Fri, 10 Jun 2016, Christian Couder wrote:
> >
> > > I fixed this by moving the "close(fd)" call just after the
> > > "apply_patch()" call.
>
> This bug in v1 was discovered by the te
On Fri, Jun 10, 2016 at 7:04 PM, Johannes Sixt wrote:
> Am 10.06.2016 um 13:11 schrieb Johannes Schindelin:
>>
>> 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
Am 10.06.2016 um 13:11 schrieb Johannes Schindelin:
On Fri, 10 Jun 2016, Christian Couder wrote:
On Fri, Jun 10, 2016 at 9:01 AM, Johannes Schindelin
wrote:
I lost track in the meantime: were those issues with unclosed file handles
and unreleased memory in the error code paths addressed system
Hi Christian,
On Fri, 10 Jun 2016, Christian Couder wrote:
> On Fri, Jun 10, 2016 at 9:01 AM, Johannes Schindelin
> 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 opportunit
Hi Dscho,
On Fri, Jun 10, 2016 at 9:01 AM, Johannes Schindelin
wrote:
> 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
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 Wi
On Thu, Jun 9, 2016 at 11:10 PM, Johannes Sixt wrote:
> Am 12.05.2016 um 20:02 schrieb Christian Couder:
>>
>>> I'll also use it in production for a while, although I am not a git-am
>>> consumer nor do I use git-rebase without -i, hence, my tests will
>>> probably
>>> only show that there is no b
Am 12.05.2016 um 20:02 schrieb Christian Couder:
On Thu, May 12, 2016 at 7:06 PM, Johannes Sixt wrote:
Am 11.05.2016 um 15:16 schrieb Christian Couder:
This is a patch series about libifying `git apply` functionality, and
using this libified functionality in `git am`, so that no 'git apply'
p
Christian Couder writes:
> On Sat, May 14, 2016 at 8:31 PM, Junio C Hamano wrote:
>>
>> I however do not see a reason why you need to expose that feature to
>> the users of "git apply". So I am not sure if any of us care deeply
>> the choice among --silent, --quiet and -q -q.
>
> About that I w
On Sat, May 14, 2016 at 8:31 PM, Junio C Hamano wrote:
>
> I however do not see a reason why you need to expose that feature to
> the users of "git apply". So I am not sure if any of us care deeply
> the choice among --silent, --quiet and -q -q.
About that I wrote in initial email above:
"The l
Christian Couder writes:
>>> So it looks to me that --quiet means something like "don't tell the
>>> story of your life, but in case of problem you are allowed to
>>> complain". In other word --quiet generally doesn't suppress error
>>> messages from error() or die().
>>
>> Right.
>>
>> And if yo
On Sat, May 14, 2016 at 8:26 AM, Johannes Schindelin
wrote:
[...]
>> >> By the way there are no tests yet for this new feature, and I am not
>> >> sure at all that "--silent" and "be_silent" are good names.
>> >
>> > If you want to follow existing code's example, we typically call this
>> > opti
Hi Chris,
On Fri, 13 May 2016, Christian Couder wrote:
> On Fri, May 13, 2016 at 8:32 AM, Johannes Schindelin
> wrote:
> >
> > On Wed, 11 May 2016, Christian Couder wrote:
> >
> >> I consider that the apply functionality is properly libified before
> >> these patches, and that they should be in
Hi Dscho,
On Fri, May 13, 2016 at 8:32 AM, Johannes Schindelin
wrote:
> Hi Chris,
>
> On Wed, 11 May 2016, Christian Couder wrote:
>
>> I consider that the apply functionality is properly libified before
>> these patches, and that they should be in a separate series, but
>> unfortunately using th
Hi Chris,
On Wed, 11 May 2016, Christian Couder wrote:
> I consider that the apply functionality is properly libified before
> these patches, and that they should be in a separate series, but
> unfortunately using the libified apply in "git am" unmasks the fact that
> "git am", since it was a she
On Thu, May 12, 2016 at 9:04 PM, Junio C Hamano wrote:
>
> As Christian said in 00/94, this probably needs to go in steps, as I
> do not think anybody wants to review fouteen rounds of 90+ patch
> series. I thought the early 40+ patches in the series were at least
> cursory reviewed already?
Yea
Johannes Sixt writes:
> I'll also use it in production for a while, although I am not a git-am
> consumer nor do I use git-rebase without -i, hence, my tests will
> probably only show that there is no bad fall-out.
It will probably only show that you do not use the part that was
touched by the s
On Thu, May 12, 2016 at 7:06 PM, Johannes Sixt wrote:
> Am 11.05.2016 um 15:16 schrieb Christian Couder:
>>
>> This is a patch series about libifying `git apply` functionality, and
>> using this libified functionality in `git am`, so that no 'git apply'
>> process is spawn anymore. This makes `git
Am 11.05.2016 um 15:16 schrieb Christian Couder:
This is a patch series about libifying `git apply` functionality, and
using this libified functionality in `git am`, so that no 'git apply'
process is spawn anymore. This makes `git am` significantly faster, so
`git rebase`, when it uses the am bac
Goal
This is a patch series about libifying `git apply` functionality, and
using this libified functionality in `git am`, so that no 'git apply'
process is spawn anymore. This makes `git am` significantly faster, so
`git rebase`, when it uses the am backend, is also significantly
faster.
Pre
20 matches
Mail list logo
