Johannes Schindelin writes:
>> Yes, it is a workaround. Making shell faster on windows would of
>> course be one possible solution to make t/t*.sh scripts go faster
>> ;-) Or update parts of t/t*.sh so that the equivalent test coverage
>> can be kept while running
Hi Duy,
On Tue, 3 Apr 2018, Duy Nguyen wrote:
> On Tue, Apr 3, 2018 at 11:31 AM, Johannes Schindelin
> wrote:
> > It is very frustrating to spend that much time with only little gains
> > here and there (and BusyBox-w32 is simply not robust enough yet, apart
> > from
On Tue, Apr 3, 2018 at 11:31 AM, Johannes Schindelin
wrote:
> It is very frustrating to spend that much time with only little gains here
> and there (and BusyBox-w32 is simply not robust enough yet, apart from
> also not showing a significant improvement in
Hi Junio,
On Fri, 30 Mar 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > What would be a *really* good strategy is: "Oh, there is a problem! Let's
> > acknowledge it and try to come up with a solution rather than a
> > work-around".
> >
> >
On Fri, Mar 30, 2018 at 8:53 PM, Johannes Schindelin
wrote:
> I think the best course of action would be to incrementally do away with
> the shell scripted test framework, in the way you outlined earlier this
> year. This would *also* buy us a wealth of other benefits,
Johannes Schindelin writes:
> What would be a *really* good strategy is: "Oh, there is a problem! Let's
> acknowledge it and try to come up with a solution rather than a
> work-around".
>
> EXPENSIVE_ON_WINDOWS is a symptom. Not a solution.
Yes, it is a workaround.
Hi Duy,
On Fri, 30 Mar 2018, Duy Nguyen wrote:
> On Fri, Mar 30, 2018 at 2:32 PM, Johannes Schindelin
> wrote:
> >
> > On Thu, 29 Mar 2018, Jeff King wrote:
> >
> >> On Thu, Mar 29, 2018 at 11:15:33AM -0700, Stefan Beller wrote:
> >>
> >> > > When calling `git config
Hi Junio,
On Fri, 30 Mar 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > I think if it's worth fixing it's worth testing for, a future change to
> > the config code could easily introduce a regression for this, and
> > particularly in this type of code
On Fri, Mar 30, 2018 at 2:32 PM, Johannes Schindelin
wrote:
> Hi,
>
> On Thu, 29 Mar 2018, Jeff King wrote:
>
>> On Thu, Mar 29, 2018 at 11:15:33AM -0700, Stefan Beller wrote:
>>
>> > > When calling `git config --unset abc.a` on this file, it leaves this
>> > >
Ævar Arnfjörð Bjarmason writes:
> I think if it's worth fixing it's worth testing for, a future change to
> the config code could easily introduce a regression for this, and
> particularly in this type of code obscure edge cases like this can point
> to bugs elsewhere.
Yup.
On Fri, Mar 30 2018, Johannes Schindelin wrote:
> On Thu, 29 Mar 2018, Jeff King wrote:
>
>> On Thu, Mar 29, 2018 at 11:15:33AM -0700, Stefan Beller wrote:
>>
>> > > When calling `git config --unset abc.a` on this file, it leaves this
>> > > (invalid) config behind:
>> > >
>> > > [
>> >
Hi,
On Thu, 29 Mar 2018, Jeff King wrote:
> On Thu, Mar 29, 2018 at 11:15:33AM -0700, Stefan Beller wrote:
>
> > > When calling `git config --unset abc.a` on this file, it leaves this
> > > (invalid) config behind:
> > >
> > > [
> > > [xyz]
> > > key = value
> >
On Thu, Mar 29, 2018 at 11:15:33AM -0700, Stefan Beller wrote:
> > When calling `git config --unset abc.a` on this file, it leaves this
> > (invalid) config behind:
> >
> > [
> > [xyz]
> > key = value
> >
> > The reason is that we try to search for the beginning of
On Thu, Mar 29, 2018 at 8:18 AM, Johannes Schindelin
wrote:
> Currently, we are slightly overzealous When removing an entry from a
> config file of this form:
>
> [abc]a
> [xyz]
> key = value
>
> When calling `git config --unset abc.a`
Currently, we are slightly overzealous When removing an entry from a
config file of this form:
[abc]a
[xyz]
key = value
When calling `git config --unset abc.a` on this file, it leaves this
(invalid) config behind:
[
[xyz]
key =
15 matches
Mail list logo