Re: Fixing the warning about warning(""); was: Re: [PATCH] difftool.c: mark a file-local symbol with static

On Thu, Jan 26, 2017 at 07:39:55AM +0100, Johannes Sixt wrote: > Am 25.01.2017 um 23:01 schrieb Jeff King: > > +#pragma GCC diagnostic ignored "-Wformat-zero-length" > > Last time I used #pragma GCC in a cross-platform project, it triggered an > "unknown pragma

Re: Fixing the warning about warning(""); was: Re: [PATCH] difftool.c: mark a file-local symbol with static

Hi Hannes, On Thu, 26 Jan 2017, Johannes Sixt wrote: > Am 25.01.2017 um 23:01 schrieb Jeff King: > > +#pragma GCC diagnostic ignored "-Wformat-zero-length" > > Last time I used #pragma GCC in a cross-platform project, it triggered > an "unknown pragma&q

Re: Fixing the warning about warning(""); was: Re: [PATCH] difftool.c: mark a file-local symbol with static

; > > static inline warning_blank_line(void) > > > { > > > warning("%s", ""); > > > } > > > > > > We'd potentially need a matching one for error(), but at last it avoids > > > macro trickery. > > >

Re: Fixing the warning about warning(""); was: Re: [PATCH] difftool.c: mark a file-local symbol with static

Am 25.01.2017 um 23:01 schrieb Jeff King: +#pragma GCC diagnostic ignored "-Wformat-zero-length" Last time I used #pragma GCC in a cross-platform project, it triggered an "unknown pragma" warning for MSVC. (It was the C++ compiler, I don't know if the C compiler would

Re: Fixing the warning about warning(""); was: Re: [PATCH] difftool.c: mark a file-local symbol with static

t reality. > > I would prefer something self-documenting, like your wrapper with a > comment. Then somebody who is looking at the implementation of > warning_blank_line() will not get tempted to turn "%s", "" into "" > because of the comment. And somebody who i

Re: Fixing the warning about warning(""); was: Re: [PATCH] difftool.c: mark a file-local symbol with static

looking at the implementation of warning_blank_line() will not get tempted to turn "%s", "" into "" because of the comment. And somebody who is looking at the callsite of warning_blank_line() will think twice before suggesting to turn it into warning(""). That does

Re: Fixing the warning about warning(""); was: Re: [PATCH] difftool.c: mark a file-local symbol with static

On Wed, Jan 25, 2017 at 11:36:50AM +0100, Johannes Schindelin wrote: > > Gross, but at least it's self documenting. :) > > > > I guess a less horrible version of that is: > > > > static inline warning_blank_line(void) > > { > > warning("%

Fixing the warning about warning(""); was: Re: [PATCH] difftool.c: mark a file-local symbol with static

> sufficient, or if we're going to get a bunch of reports from people > > > that need to be directed to the right compiler options. > > > > I view both as ugly, but probably "%s", "" is lessor of the two evils. > >

[PATCH v2 1/7] Documentation: fix warning in cat-texi.perl

Newer versions of Perl produce the warning "Unescaped left brace in regex is deprecated, passed through in regex" when an unescaped left brace occurs in a regex. Escape the brace to avoid this warning. Signed-off-by: brian m. carlson <sand...@crustytoothpaste.net> --- D

[PATCH 1/7] Documentation: fix warning in cat-texi.perl

Newer versions of Perl produce the warning "Unescaped left brace in regex is deprecated, passed through in regex" when an unescaped left brace occurs in a regex. Escape the brace to avoid this warning. Signed-off-by: brian m. carlson <sand...@crustytoothpaste.net> --- D

[PATCH] worktree: fix an 'using plain integer as NULL pointer' warning

this is a sparse warning, just in case you were wondering!] Thanks! ATB, Ramsay Jones builtin/worktree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/worktree.c b/builtin/worktree.c index 339c622e2..a1c91f154 100644 --- a/builtin/worktree.c +++ b/builtin/worktree.c

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

sy access to "recently fixed" problems) > commit c9bb5d101ca657fa466afa8c4368c43ea7b7aca8 > Author: Johannes Schindelin <johannes.schinde...@gmx.de> > Date: Mon Jan 2 17:22:33 2017 +0100 > > git_exec_path: avoid Coverity warning about unfree()d result > >

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

> > Date: Mon Jan 2 17:22:33 2017 +0100 > > git_exec_path: avoid Coverity warning about unfree()d result > > Technically, it is correct that git_exec_path() returns a possibly > malloc()ed string returned from system_path(), and it is sometimes >

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

On Sun, Jan 08, 2017 at 05:25:00PM -0800, Junio C Hamano wrote: > > If this patch is only to appease coverity (as the commit message eludes > > to) I think this may be a bad idea for upstream. If this patch fixes an > > actual problem, then the commit message needs to spell that out. > > That

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

to call system_path() just once and cache it in "static char *". How about explaining it like this then? (only the log message has been corrected; diff is from the original). commit c9bb5d101ca657fa466afa8c4368c43ea7b7aca8 Author: Johannes Schindelin <johannes.schinde...@gmx.de>

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

On Tue, Jan 3, 2017 at 1:33 PM, Johannes Schindelin wrote: > > This patch was originally only to appease Coverity, but it actually *does* > plug a very real memory leak: previously, *every* call to git_exec_path() > *possibly* returned a newly-malloc()ed buffer. Now,

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

Hi Stefan, On Tue, 3 Jan 2017, Stefan Beller wrote: > On Mon, Jan 2, 2017 at 8:22 AM, Johannes Schindelin > wrote: > > Technically, it is correct that git_exec_path() returns a possibly > > malloc()ed string. Practically, it is *sometimes* not malloc()ed. So > >

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

On Tue, Jan 03, 2017 at 12:11:25PM -0800, Stefan Beller wrote: > On Mon, Jan 2, 2017 at 8:22 AM, Johannes Schindelin > wrote: > > Technically, it is correct that git_exec_path() returns a possibly > > malloc()ed string. Practically, it is *sometimes* not malloc()ed.

Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

On Mon, Jan 2, 2017 at 8:22 AM, Johannes Schindelin wrote: > Technically, it is correct that git_exec_path() returns a possibly > malloc()ed string. Practically, it is *sometimes* not malloc()ed. So > let's just use a static variable to make it a singleton. That'll

[PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()

Technically, it is correct that git_exec_path() returns a possibly malloc()ed string. Practically, it is *sometimes* not malloc()ed. So let's just use a static variable to make it a singleton. That'll shut Coverity up, hopefully. Signed-off-by: Johannes Schindelin ---

[RFC PATCH 1/5] error/warning framework: prepare for l10n

;, err, params); + vreportf(prefix, err, params); } -static void warn_builtin(const char *warn, va_list params) +static void warn_builtin(const char *prefix, const char *warn, va_list params) { - vreportf("warning: ", warn, params); + vreportf(prefix, warn, params);

[RFC PATCH 3/5] error/warning framework framework: coccinelli rules

Provide coccinelli rules which check for error(), warning() etc. with localised argument and create a patch to replace them with error_(), warning_() etc. in order to fully localize them. Signed-off-by: Michael J Gruber <g...@drmicha.warpmail.net> --- contrib/coccinelle/errorl10n.cocc

Warning: You tried to send an email with blocked content

The UCL E-Mail Virus Protection System has been triggered by a message you sent. One or more of the original e-mail attachments have been removed and replaced with this message. * The attachment may have contained a virus or malware * The attachment may have an extension of a type unacceptable

[PATCH v2 2/5] am: Change safe_to_abort()'s not rewinding error into a warning

The error message tells the user that something went terribly wrong and the --abort could not be performed. But the --abort is performed, only without rewinding. By simply changing the error into a warning, we indicate the user that she must not try something like "git am --abort --force"

[PATCH 2/5] am: Change safe_to_abort()'s not rewinding error into a warning

The error message tells the user that something went terribly wrong and the --abort could not be performed. But the --abort is performed, only without rewinding. By simply changing the error into a warning, we indicate the user that she must not try something like "git am --abort --force"

Re: "git add -p ." raises an unexpected "warning: empty strings as pathspecs will be made invalid in upcoming releases. please use . instead if you meant to match all paths"

Brandon Williams writes: > On 11/30, Junio C Hamano wrote: >> Junio C Hamano forgot to Cc: the author of the >> most relevant change to the issue, d426430e6e ("pathspec: warn on >> empty strings as pathspec", 2016-06-22). >> ... > > I've been doing a bit of

Re: "git add -p ." raises an unexpected "warning: empty strings as pathspecs will be made invalid in upcoming releases. please use . instead if you meant to match all paths"

: > > > >> On Wed, Nov 30, 2016 at 12:31:49PM -0800, Peter Urda wrote: > >>> After upgrading to version 2.11.0 I am getting a warning about empty > >>> strings as pathspecs while using 'patch' > >>> > >>> - Ran 'git add -p .' from t

Re: "git add -p ." raises an unexpected "warning: empty strings as pathspecs will be made invalid in upcoming releases. please use . instead if you meant to match all paths"

er Urda wrote: >>> After upgrading to version 2.11.0 I am getting a warning about empty >>> strings as pathspecs while using 'patch' >>> >>> - Ran 'git add -p .' from the root of my git repository. >>> >>> - I was able to normally stage my

Re: "git add -p ." raises an unexpected "warning: empty strings as pathspecs will be made invalid in upcoming releases. please use . instead if you meant to match all paths"

Kevin Daudt <m...@ikke.info> writes: > On Wed, Nov 30, 2016 at 12:31:49PM -0800, Peter Urda wrote: >> After upgrading to version 2.11.0 I am getting a warning about empty >> strings as pathspecs while using 'patch' >> >> - Ran 'git add -p .' from the root

Re: "git add -p ." raises an unexpected "warning: empty strings as pathspecs will be made invalid in upcoming releases. please use . instead if you meant to match all paths"

On Wed, Nov 30, 2016 at 12:31:49PM -0800, Peter Urda wrote: > After upgrading to version 2.11.0 I am getting a warning about empty > strings as pathspecs while using 'patch' > > - Ran 'git add -p .' from the root of my git repository. > > - I was able to normall

"git add -p ." raises an unexpected "warning: empty strings as pathspecs will be made invalid in upcoming releases. please use . instead if you meant to match all paths"

After upgrading to version 2.11.0 I am getting a warning about empty strings as pathspecs while using 'patch' - Ran 'git add -p .' from the root of my git repository. - I was able to normally stage my changes, but was presented with a "warning: empty strings as pathspecs will be made in

git stash can recursively delete a directory with no warning

Using git 2.10.1, I recently lost the contents of an entire directory by running a "git stash" command. I don't know if this known behavior, but it seems pretty dangerous. To trigger the bug, all you have to do is check out a repository containing a symlink, delete the symlink, and then create a

Re: [PATCH] worktree: fix a sparse 'Using plain integer as NULL pointer' warning

On Wed, Nov 16, 2016 at 3:28 AM, Ramsay Jones wrote: > > Signed-off-by: Ramsay Jones > --- > > Hi Duy, > > If you need to re-roll your 'nd/worktree-move' branch, could you > please squash this into the relevant patch [commit c49e92f5c >

Re: [PATCH] worktree: fix a sparse 'Using plain integer as NULL pointer' warning

On 15/11/16 20:28, Ramsay Jones wrote: > > Signed-off-by: Ramsay Jones > --- > > Hi Duy, > > If you need to re-roll your 'nd/worktree-move' branch, could you > please squash this into the relevant patch [commit c49e92f5c > ("worktree move: refuse to move

[PATCH] worktree: fix a sparse 'Using plain integer as NULL pointer' warning

Signed-off-by: Ramsay Jones --- Hi Duy, If you need to re-roll your 'nd/worktree-move' branch, could you please squash this into the relevant patch [commit c49e92f5c ("worktree move: refuse to move worktrees with submodules", 12-11-2016)]. Also, one of the new

Re: [PATCH] sequencer: shut up clang warning

W dniu 09.11.2016 o 14:56, Johannes Schindelin pisze: > When comparing a value of type `enum todo_command` with a value that is > outside the defined enum constants, clang greets the developer with this > warning: > > comparison of constant 2 with expression of type >

Re: [PATCH] sequencer: shut up clang warning

On Wed, Nov 09, 2016 at 02:56:25PM +0100, Johannes Schindelin wrote: > When comparing a value of type `enum todo_command` with a value that is > outside the defined enum constants, clang greets the developer with this > warning: > > comparison of constant 2 with exp

[PATCH] sequencer: shut up clang warning

When comparing a value of type `enum todo_command` with a value that is outside the defined enum constants, clang greets the developer with this warning: comparison of constant 2 with expression of type 'const enum todo_command' is always true While this is arguably true *iff

[PATCH 13/13] i18n: update-index: mark warning for translation

ndex.c @@ -1127,9 +1127,9 @@ int cmd_update_index(int argc, const char **argv, const char *prefix) break; case UC_DISABLE: if (git_config_get_untracked_cache() == 1) - warning("core.untrackedCache is

Warning: You tried to send an email with blocked content

The UCL E-Mail Virus Protection System has been triggered by a message you sent. One or more of the original e-mail attachments have been removed and replaced with this message. * The attachment may have contained a virus or malware * The attachment may have an extension of a type unacceptable

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

Hi Junio, On Fri, 5 Aug 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > This setup will from now on test next & pu in the Git for Windows SDK, and > > rebase Git for Windows' current master to git.git's maint, master, next & > > pu, every morning

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

. :) Minor comments below. Thanks. -- >8 -- From: René Scharfe <l@web.de> Date: Thu, 4 Aug 2016 23:56:54 +0200 Subject: [PATCH] nedmalloc: work around overzealous GCC 6 warning With GCC 6, the strdup() function is declared with the "nonnull" attribute, stating that

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

Scharfe <l@web.de> Date: Thu, 4 Aug 2016 23:56:54 +0200 Subject: [PATCH] nedmalloc: work around overzealous GCC 6 warning With GCC 6, the strdup() function is declared with the "nonnull" attribute, stating that it is not allowed to pass a NULL value as parameter. In nedmal

Re: [PATCH 3/7] trace: use warning() for printing trace errors

Christian Couder <christian.cou...@gmail.com> writes: > On Thu, Aug 4, 2016 at 11:28 PM, Junio C Hamano <gits...@pobox.com> wrote: >> Jeff King <p...@peff.net> writes: >> >>> I wondered if that would then let us drop set_warn_routine(), but it >

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

Johannes Schindelin writes: > This setup will from now on test next & pu in the Git for Windows SDK, and > rebase Git for Windows' current master to git.git's maint, master, next & > pu, every morning after a weekday (unless I forget to turn on my laptop, > that is).

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

Hi Junio, On Thu, 4 Aug 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > With GCC 6, the strdup() function is declared with the "nonnull" > > attribute, stating that it is not allowed to pass a NULL value as > > parameter. > > > > In nedmalloc()'s

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

Hi Junio & René, On Thu, 4 Aug 2016, Junio C Hamano wrote: > Let's try it this way. How about this as a replacement? I like it (with the if (s2) test intead of if (s1), of course). But please record René as author, maybe mentioning myself with a "Diagnosed-by:" line. FWIW today's `pu` does

Re: [PATCH 3/7] trace: use warning() for printing trace errors

On Thu, Aug 4, 2016 at 11:28 PM, Junio C Hamano <gits...@pobox.com> wrote: > Jeff King <p...@peff.net> writes: > >> I wondered if that would then let us drop set_warn_routine(), but it >> looks like there are other warning() calls it cares about. So that would >>

Re: [PATCH 3/7] trace: use warning() for printing trace errors

On Thu, Aug 04, 2016 at 02:28:09PM -0700, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > I wondered if that would then let us drop set_warn_routine(), but it > > looks like there are other warning() calls it cares about. So that would > > inva

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

On Thu, Aug 04, 2016 at 11:24:32PM -0700, Junio C Hamano wrote: > I do not know if we want to worry about st_add(1, strlen(s1)) > overflow around here, though. > [...] > + size_t len = strlen(s1) + 1; I wondered that, too, but I don't think it's possible. To overflow the size_t with "+1",

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

Johannes Sixt writes: > Oh! This is a typo. You meant to check s2 for NULL. > > And the declaration for s2 should remain, of course. Yeah, the moral of the story is don't try to do something you do not usually do X-<. The second try (the log message is the same). I do not know

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

Am 05.08.2016 um 07:36 schrieb Johannes Sixt: Am 05.08.2016 um 00:39 schrieb Junio C Hamano: @@ -955,12 +955,10 @@ void **nedpindependent_comalloc(nedpool *p, size_t elems, size_t *sizes, void ** */ char *strdup(const char *s1) { -char *s2 = 0; -if (s1) { -size_t len =

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

Am 05.08.2016 um 00:39 schrieb Junio C Hamano: @@ -955,12 +955,10 @@ void **nedpindependent_comalloc(nedpool *p, size_t elems, size_t *sizes, void ** */ char *strdup(const char *s1) { - char *s2 = 0; - if (s1) { - size_t len = strlen(s1) + 1; - s2 =

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

Let's try it this way. How about this as a replacement? -- >8 -- From: Johannes Schindelin <johannes.schinde...@gmx.de> Date: Thu, 4 Aug 2016 18:07:08 +0200 Subject: [PATCH] nedmalloc: work around overzealous GCC 6 warning With GCC 6, the strdup() function is declared with the

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

René Scharfe writes: > This version of strdup() is only compiled if nedmalloc is used instead > of the system allocator. That means we can't rely on strdup() being > able to take NULL -- some (most?) platforms won't like it. Removing > the NULL check would be a more general and

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

Am 04.08.2016 um 18:07 schrieb Johannes Schindelin: With GCC 6, the strdup() function is declared with the "nonnull" attribute, stating that it is not allowed to pass a NULL value as parameter. In nedmalloc()'s reimplementation of strdup(), Postel's Law is heeded and NULL parameters are handled

Re: [PATCH 3/7] trace: use warning() for printing trace errors

Jeff King <p...@peff.net> writes: > I wondered if that would then let us drop set_warn_routine(), but it > looks like there are other warning() calls it cares about. So that would > invalidate the last paragraph here, though I still think converting the > trace errors to warning

Re: [PATCH 3/7] trace: use warning() for printing trace errors

On Thu, Aug 04, 2016 at 01:41:02PM -0700, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > Right now we just fprintf() straight to stderr, which can > > make the output hard to distinguish. It would be helpful to > > give it one of our usual pr

Re: [PATCH 3/7] trace: use warning() for printing trace errors

Jeff King <p...@peff.net> writes: > Right now we just fprintf() straight to stderr, which can > make the output hard to distinguish. It would be helpful to > give it one of our usual prefixes like "error:", "warning:", > etc. > > It doesn't make

Re: [PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

Johannes Schindelin writes: > With GCC 6, the strdup() function is declared with the "nonnull" > attribute, stating that it is not allowed to pass a NULL value as > parameter. > > In nedmalloc()'s reimplementation of strdup(), Postel's Law is heeded > and NULL

[PATCH 2/2] nedmalloc: work around overzealous GCC 6 warning

With GCC 6, the strdup() function is declared with the "nonnull" attribute, stating that it is not allowed to pass a NULL value as parameter. In nedmalloc()'s reimplementation of strdup(), Postel's Law is heeded and NULL parameters are handled gracefully. GCC 6 complains about that now because it

[PATCH 3/7] trace: use warning() for printing trace errors

Right now we just fprintf() straight to stderr, which can make the output hard to distinguish. It would be helpful to give it one of our usual prefixes like "error:", "warning:", etc. It doesn't make sense to use error() here, as the trace code is "optional" deb

[PATCH v9 34/41] write_or_die: use warning() instead of fprintf(stderr, ...)

In write_or_whine_pipe() and write_or_whine() when write_in_full() returns an error, let's print the errno related error message using warning() instead of fprintf(stderr, ...). This makes it possible to change the way it is handled by changing the current warn routine in usage.c. Signed-off

Re: [PATCH v8 33/41] write_or_die: use warning() instead of fprintf(stderr, ...)

hine(int fd, const void *buf, size_t count, const char *msg) >> { >> if (write_in_full(fd, buf, count) < 0) { >> - fprintf(stderr, "%s: write error (%s)\n", >> - msg, strerror(errno)); >> + warning("%s: wri

Re: [PATCH v8 33/41] write_or_die: use warning() instead of fprintf(stderr, ...)

; count, const char *msg) > { > if (write_in_full(fd, buf, count) < 0) { > check_pipe(errno); > - fprintf(stderr, "%s: write error (%s)\n", > - msg, strerror(errno)); > + warning("%s: write er

[PATCH v8 33/41] write_or_die: use warning() instead of fprintf(stderr, ...)

In write_or_whine_pipe() and write_or_whine() when write_in_full() returns an error, let's print the errno related error message using warning() instead of fprintf(stderr, ...). This makes it possible to change the way it is handled by changing the current warn routine in usage.c. Signed-off

[PATCH v7 32/40] write_or_die: use warning() instead of fprintf(stderr, ...)

In write_or_whine_pipe() and write_or_whine() when write_in_full() returns an error, let's print the errno related error message using warning() instead of fprintf(stderr, ...). This makes it possible to change the way it is handled by changing the current warn routine in usage.c. Signed-off

[PATCH v6 34/44] write_or_die: use warning() instead of fprintf(stderr, ...)

e_pipe(int fd, const void *buf, size_t count, const char *msg) { if (write_in_full(fd, buf, count) < 0) { check_pipe(errno); - fprintf(stderr, "%s: write error (%s)\n", - msg, strerror(errno)); + warning(&quo

[PATCH v2] regex: fix a SIZE_MAX macro redefinition warning

Since commit 56a1a3ab ("Silence GCC's \"cast of pointer to integer of a different size\" warning", 26-10-2015), sparse has been issuing a macro redefinition warning for the SIZE_MAX macro. However, gcc did not issue any such warning. After commit 56a1a3ab, in terms of th

Re: [PATCH] regex: fix a SIZE_MAX macro redefinition warning

Ramsay Jones writes: > The original version of this patch looked like this: > ... > So, just move the unconditional inclusion to the start of the compilation > unit root file, before the #include of the regex_internal.h header. > > In some ways this is a better fix,

Re: [PATCH] regex: fix a SIZE_MAX macro redefinition warning

Hi Ramsay, On Sun, 5 Jun 2016, Ramsay Jones wrote: > > Other than that, I think this patch is an improvement. > > Thanks. What do you think of replacing it with the original patch > (above)? That would work for me, too. Thanks, Dscho -- To unsubscribe from this list: send the line

Re: [PATCH] regex: fix a SIZE_MAX macro redefinition warning

On 05/06/16 08:15, Johannes Schindelin wrote: > Hi Ramsay, > > thanks for working on this! > > On Sat, 4 Jun 2016, Ramsay Jones wrote: > >> diff --git a/Makefile b/Makefile >> index 0d59718..3f6c70a 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -1987,7 +1987,7 @@ endif >> >> ifdef

Re: [PATCH] regex: fix a SIZE_MAX macro redefinition warning

Hi Ramsay, thanks for working on this! On Sat, 4 Jun 2016, Ramsay Jones wrote: > diff --git a/Makefile b/Makefile > index 0d59718..3f6c70a 100644 > --- a/Makefile > +++ b/Makefile > @@ -1987,7 +1987,7 @@ endif > > ifdef NO_REGEX > compat/regex/regex.sp compat/regex/regex.o: EXTRA_CPPFLAGS =

[PATCH] regex: fix a SIZE_MAX macro redefinition warning

Since commit 56a1a3ab ("Silence GCC's \"cast of pointer to integer of a different size\" warning", 26-10-2015), sparse has been issuing a macro redefinition warning for the SIZE_MAX macro. However, gcc did not issue any such warning. After commit 56a1a3ab, in terms of th

Re: [PATCH] xemit.c: fix a [-Wchar-subscripts] compiler warning

[sorry for duplicate] Am 26.05.2016 um 01:06 schrieb Ramsay Jones: While compiling on cygwin (x86_64), gcc complains thus: CC xdiff/xemit.o xdiff/xemit.c: In function ‘is_empty_rec’: xdiff/xemit.c:163:2: warning: array subscript has type ‘char’ [-Wchar-subscripts] while

[PATCH] xemit.c: fix a [-Wchar-subscripts] compiler warning

While compiling on cygwin (x86_64), gcc complains thus: CC xdiff/xemit.o xdiff/xemit.c: In function ‘is_empty_rec’: xdiff/xemit.c:163:2: warning: array subscript has type ‘char’ [-Wchar-subscripts] while (len > 0 && isspace(*rec)) { ^ A comment in the header rea

Re: [PATCH] crlf: Add test showing double warning on commit

Torsten Bögershausen <tbo...@web.de> writes: > Nja, (Or Nyes in English), the old handling tried to be "nice" to the user: > $ git add text # gave warning > #User forgets, does other things, git reset HEAD > $ git commit # Gave the warning one m

Re: [PATCH] crlf: Add test showing double warning on commit

may be an indexed blob while dst may be a file in the > working tree). > >> If yes, we may need to introduce a flag besides >> #define CHECK_SIZE_ONLY 1 >> #define CHECK_BINARY2 >> to suppress the conversion warning ?? > > I do not think that belongs to

Re: [PATCH] crlf: Add test showing double warning on commit

may be an indexed blob while dst may be a file in the > working tree). > >> If yes, we may need to introduce a flag besides >> #define CHECK_SIZE_ONLY 1 >> #define CHECK_BINARY2 >> to suppress the conversion warning ?? > > I do not think that belongs to dif

Re: [PATCH] crlf: Add test showing double warning on commit

yes, we may need to introduce a flag besides > #define CHECK_SIZE_ONLY 1 > #define CHECK_BINARY2 > to suppress the conversion warning ?? I do not think that belongs to diff_populate_filespec() at all. Why should conversion routine give this warning when called by diff_populate_filespec

[PATCH] crlf: Add test showing double warning on commit

0-crlf.sh b/t/t0020-crlf.sh index f94120a..188b1dd 100755 --- a/t/t0020-crlf.sh +++ b/t/t0020-crlf.sh @@ -74,7 +74,7 @@ test_expect_success 'safecrlf: autocrlf=true mixed LF/CRLF' ' test_must_fail git add mixed ' -test_expect_success 'safecrlf: print warning only once' ' +test_expect_succe

[PATCH v2 85/94] write_or_die: use warning() instead of fprintf(stderr, ...)

e_pipe(int fd, const void *buf, size_t count, const char *msg) { if (write_in_full(fd, buf, count) < 0) { check_pipe(errno); - fprintf(stderr, "%s: write error (%s)\n", - msg, strerror(errno)); + warning(&quo

[PATCH v3 36/41] sha1_file.c: use {error,die,warning}_errno()

nsigned char *sha1, char *hdr, int hdrlen, utb.actime = mtime; utb.modtime = mtime; if (utime(tmp_file.buf, ) < 0) - warning("failed utime() on %s: %s", - tmp_file.buf, strerror(errno)); + war

[PATCH v2 36/41] sha1_file.c: use {error,die,warning}_errno()

nsigned char *sha1, char *hdr, int hdrlen, utb.actime = mtime; utb.modtime = mtime; if (utime(tmp_file.buf, ) < 0) - warning("failed utime() on %s: %s", - tmp_file.buf, strerror(errno)); + war

[PATCH 36/41] sha1_file.c: use {error,die,warning}_errno()

nsigned char *sha1, char *hdr, int hdrlen, utb.actime = mtime; utb.modtime = mtime; if (utime(tmp_file.buf, ) < 0) - warning("failed utime() on %s: %s", - tmp_file.buf, strerror(errno)); + war

[PATCH 1/4] t3033: avoid 'ambiguous refs' warning

Because "test_commit five" creates a commit and point it with a tag 'five', doing so on a branch whose name is 'five' will later result in an 'ambiguous refs' warning. Even though it is harmless because all the later references are for the tag, there is no reason for the branch to be ca

Re: Compiler warning under cygwin/mingw

SZEDER Gábor <sze...@ira.uka.de> writes: > Hi, > >> > And MINGW is not happy for other reasons: >> > >> > builtin/rev-parse.c: In function 'cmd_rev_parse': >> > builtin/rev-parse.c:775:12: warning: implicit declaration of function

Re: Warning about conflict markers - undocumented 'diff --check' feature & suggestion

On Tue, Mar 29, 2016 at 9:23 PM, Junio C Hamano wrote: > Ori Avtalion writes: > I am not sure what "similar functionality" you are imagining. > > "git add" does not show any changes, it just does what it was told > to do. If the user is unsure, s/he should

Re: Warning about conflict markers - undocumented 'diff --check' feature & suggestion

Ori Avtalion writes: > If my change introduces a few words that exceed asciidoc's ~72-char line > width, > should I reformat the entire paragraph? (thus making it had to identify what > changed exactly) You should try to minimize the damage, but shouldn't go overboard ;-)

Re: Warning about conflict markers - undocumented 'diff --check' feature & suggestion

On Tue, Mar 29, 2016 at 2:01 AM, Junio C Hamano wrote: > Ori Avtalion writes: > > Thanks for digging (even though I do not think the message you > quoted has much to do with this). Oops, you are correct! I had several tabs open digging through the archives

Re: Warning about conflict markers - undocumented 'diff --check' feature & suggestion

Ori Avtalion <o...@avtalion.name> writes: > A bug report and a suggestion: > > `git diff --check` has been warning about conflict markers since 2008: > https://marc.info/?l=git=122398500726634=2 > > This is an undocumented feature. The current documentation for

Warning about conflict markers - undocumented 'diff --check' feature & suggestion

A bug report and a suggestion: `git diff --check` has been warning about conflict markers since 2008: https://marc.info/?l=git=122398500726634=2 This is an undocumented feature. The current documentation for the flag only mentions "whitespace errors". This check will also be useful i

Re: [PATCH v2 1/4] lib-gpg: drop unnecessary "missing GPG" warning

On Tue, Mar 15, 2016 at 3:33 PM, Johannes Schindelin wrote: > On Sun, 6 Mar 2016, Eric Sunshine wrote: >> I also sneaked in a minor style cleanup. > > Isn't this "snuck"? I'm no grammarian, but [1] says either would be fine (and we know that the Internet never lies).

Re: [PATCH v2 1/4] lib-gpg: drop unnecessary "missing GPG" warning

Hi Eric, On Sun, 6 Mar 2016, Eric Sunshine wrote: > I also sneaked in a minor style cleanup. Isn't this "snuck"? The patch is fine. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at

[PATCH v2 1/4] lib-gpg: drop unnecessary "missing GPG" warning

When 37d3e85 (t7004: factor out gpg setup, 2011-09-07) pulled gpg detection code out of t7004-tag.sh and turned it into a standard test prerequisite, it added an unconditional "missing GPG" warning when gpg is not detected. However, this is redundant since all tests which require GPG al

Re: Compiler warning under cygwin/mingw

On 03/03/16 03:33, Ramsay Jones wrote: > > > On 29/02/16 12:32, Ramsay Jones wrote: >> >> >> On 29/02/16 10:40, Torsten Bögershausen wrote: >>> That compiles OK, thanks. >>> >>> >>> Sorry for high-jacking this thread, but while com

Re: Compiler warning under cygwin/mingw

On 29/02/16 12:32, Ramsay Jones wrote: > > > On 29/02/16 10:40, Torsten Bögershausen wrote: >> That compiles OK, thanks. >> >> >> Sorry for high-jacking this thread, but while compiling under CYGWIN, >> found one warning: >> >>LINK git-

Re: Compiler warning under cygwin/mingw (was: fix for 50a6c8e)

Hi, > > And MINGW is not happy for other reasons: > > > > builtin/rev-parse.c: In function 'cmd_rev_parse': > > builtin/rev-parse.c:775:12: warning: implicit declaration of function > > 'realpath' [-Wimplicit-function-declaration] > >

Re: Compiler warning under cygwin/mingw

On 29/02/16 10:40, Torsten Bögershausen wrote: > That compiles OK, thanks. > > > Sorry for high-jacking this thread, but while compiling under CYGWIN, > found one warning: > >LINK git-credential-store.exe > CC daemon.o > daemon.c: In function ‘drop_priv

Re: Compiler warning under cygwin/mingw (was: fix for 50a6c8e)

On Mon, Feb 29, 2016 at 11:40:59AM +0100, Torsten Bögershausen wrote: > That compiles OK, thanks. > > Sorry for high-jacking this thread, but while compiling under CYGWIN, > found one warning: > >LINK git-credential-store.exe > CC daemon.o > daemon.c: In f

<    1   2   3   4   5   6   7   8   9   10   >