Johannes Schindelin writes:
> This is the offending part from last night's build:
>
> -- snipsnap --
> 2016-11-16T00:31:57.5321220Z copy.c: In function 'copy_dir_1':
> 2016-11-16T00:31:57.5321220Z copy.c:369:8: error: implicit declaration of
> function 'lchown'
Hi,
On Tue, 15 Nov 2016, Johannes Schindelin wrote:
> On Mon, 14 Nov 2016, Junio C Hamano wrote:
>
> > Dscho's mention of 'still times out' may be an indiciation that
> > something unspecified on 'pu' is not ready to be merged to 'next',
> > but blocking all of 'pu' with a blanket statement is
Hi Junio,
On Mon, 14 Nov 2016, Junio C Hamano wrote:
> Dscho's mention of 'still times out' may be an indiciation that
> something unspecified on 'pu' is not ready to be merged to 'next',
> but blocking all of 'pu' with a blanket statement is not useful,
> and that was where my response comes
On 14/11/16 17:01, Jeff King wrote:
> On Mon, Nov 14, 2016 at 05:35:56PM +0100, Torsten Bögershausen wrote:
>
>>> Git 'pu' does not compile on macOS right now:
>>> builtin/bisect--helper.c:299:6: error: variable 'good_syn' is used
>>> uninitialized
>>> whenever 'if' condition is true
Lars Schneider writes:
>> On 13 Nov 2016, at 02:13, Junio C Hamano wrote:
>> ...
>> Earlier you said 'pu' did even not build, but do we know where this
>> "still times out" comes from? As long as I don't merge anything
>> prematurely, which I need
On Mon, Nov 14, 2016 at 05:35:56PM +0100, Torsten Bögershausen wrote:
> > What is the goal for 'pu'?
>
> > (1) Builds clean on all platforms + passes all tests
> Yes
> > (2) Builds clean on all platforms
> Yes
> > (3) Builds clean on Linux
> Yes
> > (4) Just makes new topics easily available to
On 14.11.16 10:11, Lars Schneider wrote:
>
>> On 13 Nov 2016, at 02:13, Junio C Hamano wrote:
>>
>> Johannes Schindelin writes:
>>
Thanks. Dscho, does this fix both of these issues to you?
>>>
>>> Apparently it does because the CI jobs for
> On 13 Nov 2016, at 02:13, Junio C Hamano wrote:
>
> Johannes Schindelin writes:
>
>>> Thanks. Dscho, does this fix both of these issues to you?
>>
>> Apparently it does because the CI jobs for `master` and for `next` pass.
>
> OK, thanks for
Johannes Schindelin writes:
>> Thanks. Dscho, does this fix both of these issues to you?
>
> Apparently it does because the CI jobs for `master` and for `next` pass.
OK, thanks for a quick confirmation.
> The one for `pu` still times out, of course.
Earlier you
Hi Junio,
On Fri, 11 Nov 2016, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > We have to use $PWD instead of $(pwd) because on Windows the latter
> > would add a C: style path to bash's Unix-style $PATH variable, which
> > becomes confused by the colon after the drive
Johannes Sixt writes:
> We have to use $PWD instead of $(pwd) because on Windows the latter
> would add a C: style path to bash's Unix-style $PATH variable, which
> becomes confused by the colon after the drive letter. ($PWD is a
> Unix-style path.)
>
> In the case of
On Fri, Nov 11, 2016 at 06:31:48PM +0100, Johannes Sixt wrote:
> We have to use $PWD instead of $(pwd) because on Windows the latter
> would add a C: style path to bash's Unix-style $PATH variable, which
> becomes confused by the colon after the drive letter. ($PWD is a
> Unix-style path.)
>
>
We have to use $PWD instead of $(pwd) because on Windows the latter
would add a C: style path to bash's Unix-style $PATH variable, which
becomes confused by the colon after the drive letter. ($PWD is a
Unix-style path.)
In the case of GIT_ALTERNATE_OBJECT_DIRECTORIES, bash on Windows
assembles a
13 matches
Mail list logo