SZEDER Gábor writes:
> Junio,
>
> On Thu, Jul 18, 2019 at 05:22:34PM +0200, SZEDER Gábor wrote:
>> Subject: [PATCH] travis-ci: build with GCC 4.8 as well
>
> This patch conflicts with topic 'js/trace2-json-schema', and the
> current conflict resolution in 'pu' is not quite correct.
Thanks.
"git
Junio,
On Thu, Jul 18, 2019 at 05:22:34PM +0200, SZEDER Gábor wrote:
> Subject: [PATCH] travis-ci: build with GCC 4.8 as well
This patch conflicts with topic 'js/trace2-json-schema', and the
current conflict resolution in 'pu' is not quite correct.
> diff --git a/ci/run-build-and-tests.sh b/ci/r
Carlo Arenas writes:
> On Thu, Jul 18, 2019 at 6:31 PM Jonathan Nieder wrote:
>>
>> This makes sense to me. Not really for the 'for' loop declaration
>> aspect: for that, I'd want some more specialized tool that allows
>> turning on such a check specifically. But more because Ubuntu trusty
>>
On Thu, Jul 18, 2019 at 6:31 PM Jonathan Nieder wrote:
>
> This makes sense to me. Not really for the 'for' loop declaration
> aspect: for that, I'd want some more specialized tool that allows
> turning on such a check specifically. But more because Ubuntu trusty
> is still a platform that some
SZEDER Gábor wrote:
> I expected that this will eventually happen after Travis CI's default
> Linux image recently changed from Ubuntu 14.04 to 16.04; explanation
> in the commit message below.
>
> With that patch issues like this could be caught earlier, while they
> are only in 'pu' but not yet
On Thu, Jul 18, 2019 at 09:12:52AM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > With that patch issues like this could be caught earlier, while they
> > are only in 'pu' but not yet in 'next'. But do we really want to do
> > that, is that the right tradeoff?
>
> I am sort of in fav
On Thu, Jul 18, 2019 at 11:22 AM SZEDER Gábor wrote:
> C99 'for' loop initial declaration, i.e. 'for (int i = 0; i < n; i++)',
> is not allowed in Git's codebase yet, to maintain compatibility with
> some older compilers.
> [...]
> [1] The Azure Pipelines builds have been using Ubuntu 16.04 images
SZEDER Gábor writes:
> With that patch issues like this could be caught earlier, while they
> are only in 'pu' but not yet in 'next'. But do we really want to do
> that, is that the right tradeoff?
I am sort of in favor of having at least one build with an older
compiler without "-std=c99", lik
On Tue, Jul 16, 2019 at 09:53:59AM -0700, Junio C Hamano wrote:
> Carlo Arenas writes:
> >> + for (struct ref *it = remote_refs; it; it =
> >> it->next)
> >
> > moving "struct ref it" out of the loop, allows for building with ancient
> > compilers that don't support C90 (ev
On Tue, Jul 16, 2019 at 9:54 AM Junio C Hamano wrote:
>
> Does everything else compile OK with your rather old compiler on
> Centos 6?
yes, they were a few -Wmaybe-uninitialized warnings but they were most
likely false positives.
gcc 4.4.7 aborts the build (even without -Werror) with the followi
Carlo Arenas writes:
> On Tue, Jul 9, 2019 at 2:16 PM Emily Shaffer wrote:
>>
>> diff --git a/transport.c b/transport.c
>> index f1fcd2c4b0..d768bc275e 100644
>> --- a/transport.c
>> +++ b/transport.c
>> @@ -1226,6 +1226,19 @@ int transport_push(struct repository *r,
>> err = pus
On Tue, Jul 9, 2019 at 2:16 PM Emily Shaffer wrote:
>
> diff --git a/transport.c b/transport.c
> index f1fcd2c4b0..d768bc275e 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -1226,6 +1226,19 @@ int transport_push(struct repository *r,
> err = push_had_errors(remote_refs);
>
On Wed, Jul 10, 2019 at 10:53:30AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> + # the new branch should not have been created upstream
> >> + test_must_fail git -C "$d" rev-parse refs/heads/atomic &&
> >
> > The new branch should not have been created; if this rev-parse
> > su
Emily Shaffer writes:
> Hmm. I'd like to argue that part of the requirement is to show the user
> what happened; for example, in an earlier iteration I was not
> successfully reporting the "collateral damage" refs to the user, even
> though they were not being pushed. To that end, I'd rather chec
On Wed, Jul 10, 2019 at 10:44:22AM -0700, Junio C Hamano wrote:
> Emily Shaffer writes:
>
> > +test_expect_success 'push --atomic also prevents branch creation, reports
> > collateral' '
> > + # Setup upstream repo - empty for now
> > + d=$HTTPD_DOCUMENT_ROOT_PATH/atomic-branches.git &&
> >
Junio C Hamano writes:
>> +# the new branch should not have been created upstream
>> +test_must_fail git -C "$d" rev-parse refs/heads/atomic &&
>
> The new branch should not have been created; if this rev-parse
> succeeded, it would be a bug.
One thing I forgot. If refs/heads/atomic did
Emily Shaffer writes:
> +test_expect_success 'push --atomic also prevents branch creation, reports
> collateral' '
> + # Setup upstream repo - empty for now
> + d=$HTTPD_DOCUMENT_ROOT_PATH/atomic-branches.git &&
> + git init --bare "$d" &&
> + test_config -C "$d" http.receivepack
Teach transport-helper how to notice if skipping a ref during push would
violate atomicity on the client side. We notice that a ref would be
rejected, and choose not to send it, but don't notice that if the client
has asked for --atomic we are violating atomicity if all the other
pushes we are send
18 matches
Mail list logo
