Re: [PATCH 3/3] sha1-file: change alternate "error:" message to "warning:"

On Wed, Dec 05, 2018 at 12:37:58PM +0900, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > Change the "error" message emitted by alt_odb_usable() to be a > > "warning" instead. As noted in commits leading up to this one this has >

Re: [PATCH 3/3] sha1-file: change alternate "error:" message to "warning:"

Ævar Arnfjörð Bjarmason writes: > Change the "error" message emitted by alt_odb_usable() to be a > "warning" instead. As noted in commits leading up to this one this has > never impacted the exit code ever since the check was initially added > in 26125f6b9b (&quo

[PATCH 3/3] sha1-file: change alternate "error:" message to "warning:"

Change the "error" message emitted by alt_odb_usable() to be a "warning" instead. As noted in commits leading up to this one this has never impacted the exit code ever since the check was initially added in 26125f6b9b ("detect broken alternates.", 2006-02-22). It

Re: [PATCH] Prevent warning

On Mon, Oct 29, 2018 at 03:39:30PM +, Pete wrote: > Prevent the following warning in the web server error log: > gitweb.cgi: Odd number of elements in anonymous hash at > /usr/share/gitweb/gitweb.cgi line 3305 > [...] > - $remotes{$remot

Re: [PATCH] Prevent warning

Thanks for the patch. Could you please sign it off ? The other remark would be if the header line could be written longer than just "Prevent warning". to give people digging into the Git history an initial information, where the warning occured and from which module it was caused. May be

[PATCH] Prevent warning

Prevent the following warning in the web server error log: gitweb.cgi: Odd number of elements in anonymous hash at /usr/share/gitweb/gitweb.cgi line 3305 --- gitweb/gitweb.perl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index

[PATCH v2] sequencer: cleanup for gcc warning in non developer mode

as shown by: sequencer.c: In function ‘write_basic_state’: sequencer.c:2392:37: warning: zero-length gnu_printf format string [-Wformat-zero-length] write_file(rebase_path_verbose(), ""); where write_file will create an empty file if told to write an empty string as can b

Re: [PATCH] sequencer: cleanup for gcc 8.2.1 warning

5d9 ("rebase -i: move rebase--helper modes to rebase--interactive", 2018-09-27) would be a good idea to include also enabling this warning in developer mode so it doesn't sneak back?, presume as the last patch of the refactor below?, FWIW this is the only case in current pu, and I suspec

Re: [PATCH] sequencer: cleanup for gcc 8.2.1 warning

Carlo Arenas writes: > would something like this work better? (not to apply, and probably mangled) At least call it "create_empty_file(path)" instead. "touch" is primarily to update the last-modified-time timestamp of a file. If the file does not exist, it is created while doing so, but when

Re: [PATCH] sequencer: cleanup for gcc 8.2.1 warning

On Wed, Oct 24, 2018 at 11:22 PM Junio C Hamano wrote: > and they would read naturally. But may be it is a bit too cute an > idea? I dunno. my first idea was to replace it with a helper called touch_file, since I was expecting it will be a popular operation as flag files are common in shell

Re: [PATCH] sequencer: cleanup for gcc 8.2.1 warning

Junio C Hamano writes: > I'd have to say that the ability to create an empty file is more > important in the longer term. Can't the workaround be done to > write_file() instead? I actually do not mind if the solution were > to introduce a newhelper "write_empty_file()", but the way it is >

Re: [PATCH] sequencer: cleanup for gcc 8.2.1 warning

Carlo Marcelo Arenas Belón writes: > sequencer.c: In function ‘write_basic_state’: > sequencer.c:2392:37: warning: zero-length gnu_printf format string > [-Wformat-zero-length] >write_file(rebase_path_verbose(), ""); The change may squelch the above warning,

[PATCH] sequencer: cleanup for gcc 8.2.1 warning

sequencer.c: In function ‘write_basic_state’: sequencer.c:2392:37: warning: zero-length gnu_printf format string [-Wformat-zero-length] write_file(rebase_path_verbose(), ""); Signed-off-by: Carlo Marcelo Arenas Belón --- sequencer.c | 2 +- 1 file changed, 1 insertion(+),

Re: [PATCH] fetch: fix compilation warning

Ramsay Jones writes: > You probably already know, but I had to add this on top of the 'pu' > branch to get a clean compile tonight (your 'jc/war-on-string-list' > branch). It was not just about squelching a warning but simply broken code that deserved to be warned/errored. I think wha

[PATCH] fetch: fix compilation warning

commit 440fc7c0729 ("fetch: replace string-list used as a look-up table with a hashmap", 2018-09-25) renamed a string-list variable (while adding a hashmap of the same name) and forgot to rename the string-list variable in a call to string_list_clear(). Signed-off-by: Ramsay Jones --- Hi

Re: [PATCH] read-cache.c: fix a sparse warning

pointer to a structure (a quite common choice), whereas on Linux it >>>> is defined as an 'unsigned long int'. >>>> >>>> On cygwin, but not on Linux, 'sparse' currently complains about an >>>> initialiser used on a 'struct load_index_exte

Re: [PATCH] read-cache.c: fix a sparse warning

ned as an 'unsigned long int'. >>> >>> On cygwin, but not on Linux, 'sparse' currently complains about an >>> initialiser used on a 'struct load_index_extensions' variable, whose >>> first field may be a pthread handle (if not compiled with NO_PTHREADS >>>

Re: [PATCH] read-cache.c: fix a sparse warning

' variable, whose first field may be a pthread handle (if not compiled with NO_PTHREADS set). In order to fix the warning, move the (conditional) pthread field to the end of the struct and change the initialiser to use a NULL, since the new (unconditional) first field is a pointer type. Signed-off

Re: [PATCH] read-cache.c: fix a sparse warning

le, whose > first field may be a pthread handle (if not compiled with NO_PTHREADS > set). > > In order to fix the warning, move the (conditional) pthread field to > the end of the struct and change the initialiser to use a NULL, since > the new (unconditional) first field is a

[PATCH] read-cache.c: fix a sparse warning

to fix the warning, move the (conditional) pthread field to the end of the struct and change the initialiser to use a NULL, since the new (unconditional) first field is a pointer type. Signed-off-by: Ramsay Jones --- Hi Ben, If you need to re-roll your 'bp/read-cache-parallel' branch, could you

Re: [PATCH] config.mak.uname: resolve FreeBSD iconv-related compilation warning

On Fri, Aug 31, 2018 at 1:00 PM Jonathan Nieder wrote: > > From: Jonathan Nieder > > OLD_ICONV has long been needed by FreeBSD so config.mak.uname defines > > it unconditionally. However, recent versions do not need it, and its > > presence results in compilation warnings. Resolve this issue by

Re: [PATCH] config.mak.uname: resolve FreeBSD iconv-related compilation warning

On Fri, Aug 31, 2018 at 7:54 AM Ævar Arnfjörð Bjarmason wrote: > On Fri, Aug 31, 2018 at 11:52 AM Eric Sunshine > wrote: > > OLD_ICONV has long been needed by FreeBSD so config.mak.uname defines > > it unconditionally. However, recent versions do not need it, and its > > presence results in

Re: [PATCH] config.mak.uname: resolve FreeBSD iconv-related compilation warning

Eric Sunshine wrote: > From: Jonathan Nieder > > OLD_ICONV has long been needed by FreeBSD so config.mak.uname defines > it unconditionally. However, recent versions do not need it, and its > presence results in compilation warnings. Resolve this issue by defining > OLD_ICONV only for older

Re: [PATCH] config.mak.uname: resolve FreeBSD iconv-related compilation warning

On Fri, Aug 31, 2018 at 11:52 AM Eric Sunshine wrote: > OLD_ICONV has long been needed by FreeBSD so config.mak.uname defines > it unconditionally. However, recent versions do not need it, and its > presence results in compilation warnings. Resolve this issue by defining > OLD_ICONV only for

[PATCH] config.mak.uname: resolve FreeBSD iconv-related compilation warning

From: Jonathan Nieder OLD_ICONV has long been needed by FreeBSD so config.mak.uname defines it unconditionally. However, recent versions do not need it, and its presence results in compilation warnings. Resolve this issue by defining OLD_ICONV only for older FreeBSD versions. Specifically,

[PATCH 0/1] Fix a recently-introduced compile warning

: it is based on nd/clone-case-smashing-warning. Johannes Schindelin (1): mark_colliding_entries(): fix incorrect #if...#endif guard entry.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) base-commit: f80218bf4e65ccc06cc9173c0ac5a5520d380f36 Published-As: https://github.com/gitgitgadget

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

Signed-off-by: Ramsay Jones --- Hi Pratik, If you need to re-roll your 'pk/rebase-in-c-4-opts' branch, could you please squash this into the relevant patch (commit b0721e7b48, "builtin rebase: support `-C` and `--whitespace=`", 2018-08-08). Thanks! ATB, Ramsay Jones builtin/rebase.c | 2

Re: [PATCH v4 16/21] range-diff --dual-color: fix bogus white-space warning

Hi Stefan, On Mon, 23 Jul 2018, Stefan Beller wrote: > On Sat, Jul 21, 2018 at 3:05 PM Johannes Schindelin via GitGitGadget > wrote: > > > > From: Johannes Schindelin > > > > When displaying a diff of diffs, it is possible that there is an outer > > `+` before a context line. That happens when

Re: [PATCH v4 16/21] range-diff --dual-color: fix bogus white-space warning

Junio C Hamano writes: > It is pleasing to see that with a surprisingly clean and small > change like this we can exempt the initial space byte from > SP-before-HT check and from Indent-with-non-tab at the same time. > > Very nice. > > One reason why a surprisingly small special case is required

Re: [PATCH v4 16/21] range-diff --dual-color: fix bogus white-space warning

"Johannes Schindelin via GitGitGadget" writes: > @@ -177,8 +178,16 @@ static unsigned ws_check_emit_1(const char *line, int > len, unsigned ws_rule, > if (trailing_whitespace == -1) > trailing_whitespace = len; > > + if ((ws_rule & WS_IGNORE_FIRST_SPACE) && len &&

Re: [PATCH v4 16/21] range-diff --dual-color: fix bogus white-space warning

On Sat, Jul 21, 2018 at 3:05 PM Johannes Schindelin via GitGitGadget wrote: > > From: Johannes Schindelin > > When displaying a diff of diffs, it is possible that there is an outer > `+` before a context line. That happens when the context changed between > old and new commit. When that context

[PATCH v4 16/21] range-diff --dual-color: fix bogus white-space warning

From: Johannes Schindelin When displaying a diff of diffs, it is possible that there is an outer `+` before a context line. That happens when the context changed between old and new commit. When that context line starts with a tab (after the space that marks it as context line), our diff

Re: [PATCH v3 16/20] range-diff --dual-color: work around bogus white-space warning

Hi Stefan, On Tue, 10 Jul 2018, Stefan Beller wrote: > On Tue, Jul 10, 2018 at 3:08 AM Johannes Schindelin > wrote: > > > > On Mon, 9 Jul 2018, Junio C Hamano wrote: > > > > > I also wonder if we should be feeding the context lines to ws.c > > > machinery in the first place though. > > > > It

Re: [PATCH v3 16/20] range-diff --dual-color: work around bogus white-space warning

On Tue, Jul 10, 2018 at 3:08 AM Johannes Schindelin wrote: > > Hi Junio, > > On Mon, 9 Jul 2018, Junio C Hamano wrote: > > > I also wonder if we should be feeding the context lines to ws.c > > machinery in the first place though. > > It *is* confusing, I know. The entire "diff of diffs" concept

Re: [PATCH v3 16/20] range-diff --dual-color: work around bogus white-space warning

Johannes Schindelin writes: > Hi Junio, > > On Mon, 9 Jul 2018, Junio C Hamano wrote: > >> I also wonder if we should be feeding the context lines to ws.c >> machinery in the first place though. > > It *is* confusing, I know. The entire "diff of diffs" concept *is* > confusing. I just don't know

Re: [PATCH v3 16/20] range-diff --dual-color: work around bogus white-space warning

Hi Junio, On Mon, 9 Jul 2018, Junio C Hamano wrote: > I also wonder if we should be feeding the context lines to ws.c > machinery in the first place though. It *is* confusing, I know. The entire "diff of diffs" concept *is* confusing. I just don't know about a better alternative. So hear me

Re: [PATCH v3 16/20] range-diff --dual-color: work around bogus white-space warning

Stefan Beller writes: > On Tue, Jul 3, 2018 at 4:26 AM Johannes Schindelin via GitGitGadget > wrote: >> >> From: Johannes Schindelin >> >> When displaying a diff of diffs, it is possible that there is an outer >> `+` before a context line. That happens when the context changed between >> old

Re: [PATCH v3 16/20] range-diff --dual-color: work around bogus white-space warning

set = diff_get_color_opt(o, DIFF_FRAGINFO); > else if (c != '+') > set = diff_get_color_opt(o, DIFF_CONTEXT); > + /* Avoid space-before-tab warning */ > + if (c

[PATCH v3 16/20] range-diff --dual-color: work around bogus white-space warning

, DIFF_CONTEXT); + /* Avoid space-before-tab warning */ + if (c == ' ' && (len < 2 || line[1] == '\t' || +line[1] == '\r' || line[1] == '\n')) { +

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Sat, Jun 02, 2018 at 06:46:31AM +0200, Duy Nguyen wrote: > > if (used_deprecated_reflog_option) { > > - warning("the '-l' alias for '--create-reflog' is > > deprecated;"); > > - warning("it wil

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Fri, May 25, 2018 at 4:40 AM, Jeff King wrote: > -- >8 -- > Subject: [PATCH] branch: customize "-l" warning in list mode > > People mistakenly use "git branch -l", thinking that it > triggers list mode. It doesn't, but the lack of non-option > ar

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

I > guess the right rule is to warn when we are not in list-mode, and > otherwise quietly accept it. > > That does mean that anybody who misses the deprecation warning may be > surprised when "branch -l foo" starts listing instead of creating a > branch with a reflog (wherea

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Wednesday 30 May 2018 08:22 AM, Junio C Hamano wrote: Jeff King writes: Right, what I meant by "gentler" is that we continue to perform the same behavior as the old version, alongside the warning. It's arguable here because running "git branch -l" has _always_ been wr

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Wed, May 30, 2018 at 11:52:19AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > Right, what I meant by "gentler" is that we continue to perform the same > > behavior as the old version, alongside the warning. It's arguable here > > because running

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Wed, May 30, 2018 at 11:48:32AM +0900, Junio C Hamano wrote: > Jeff King writes: > > >> - if (list) { > >> - warning("the '-l' option is an alias for > >> '--create-reflog' and"); > >> -

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Jeff King writes: > Right, what I meant by "gentler" is that we continue to perform the same > behavior as the old version, alongside the warning. It's arguable here > because running "git branch -l" has _always_ been wrong. It's just wrong > in a way that h

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Jeff King writes: >> -if (list) { >> - warning("the '-l' option is an alias for >> '--create-reflog' and"); >> -warning("has no effect in list mode. This option will >> soon be"); >> -

Re: [PATCH] commit-graph: fix a sparse 'integer as NULL pointer' warning

n 5/29/2018 4:01 PM, Ramsay Jones wrote: Signed-off-by: Ramsay Jones --- Hi Derrick, If you need to re-roll your 'ds/commit-graph-fsck' branch (pu@a84e06bc0f), could you please squash this into the relevant patch (commit 80453b4529, "commit-graph: add 'verify' subcommand", 2018-05-24). [No,

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

1-removal). > [...] > - if (used_deprecated_reflog_option) { > - if (list) { > - warning("the '-l' option is an alias for > '--create-reflog' and"); > - warning("has no effect in list mode. This option will > soon be"); > -

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

up_auto_pager("branch", 1); - if (used_deprecated_reflog_option) { - if (list) { - warning("the '-l' option is an alias for '--create-reflog' and"); - warning("has no effect in list mode. This option will soon

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Sun, May 27, 2018 at 12:15:40AM +0530, Kaartic Sivaraam wrote: > > Hmm, actually, I suppose the true value of the warning is to help people > > doing "git branch -l foo", and it would still work there. The "more > > extreme" from your sugges

[PATCH] commit-graph: fix a sparse 'integer as NULL pointer' warning

Signed-off-by: Ramsay Jones --- Hi Derrick, If you need to re-roll your 'ds/commit-graph-fsck' branch (pu@a84e06bc0f), could you please squash this into the relevant patch (commit 80453b4529, "commit-graph: add 'verify' subcommand", 2018-05-24). [No, No, that was the one in graph_read(). :-D

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Friday 25 May 2018 08:10 AM, Jeff King wrote: > Subject: [PATCH] branch: customize "-l" warning in list mode > > People mistakenly use "git branch -l", thinking that it > triggers list mode. It doesn't, but the lack of non-option > arguments in that

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Friday 25 May 2018 01:01 AM, Jeff King wrote: > On Thu, May 24, 2018 at 03:22:14PM -0400, Jeff King wrote: > > Hmm, actually, I suppose the true value of the warning is to help people > doing "git branch -l foo", and it would still work there. The "more > extr

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Jeff King <p...@peff.net> writes: >> By the way, this is one of these times when I feel that we should >> have a better multi-line message support in die/error/warning/info >> functions. Ideally, I should be able to write >> >> warning(_("the '-l

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Junio C Hamano writes: > With these two patches queued on top of jk/branch-l-0-deprecation, > the follow-up patches jk/branch-l-1-removal that makes 'branch -l' > to fail and then jk/branch-l-2-reincarnation that makes 'branch -l' > a synonym to 'branch --list' needs rebasing.

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Junio C Hamano writes: > Yup, thanks for being extra explicit. I do imagine there are quite > a few of us who would be puzzled without this update (but with the > previous one to unhide it from behind the pager). With these two patches queued on top of

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Fri, May 25, 2018 at 06:14:16PM +0900, Junio C Hamano wrote: > Junio C Hamano <gits...@pobox.com> writes: > > >> - warning("the '-l' alias for '--create-reflog' is deprecated;"); > >> - warning("it will be removed in a futu

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Junio C Hamano <gits...@pobox.com> writes: >> - warning("the '-l' alias for '--create-reflog' is deprecated;"); >> -warning("it will be removed in a future version of Git"); >> + if (list) { >> +

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

9 (branch: deprecate "-l" option, 2018-03-26) > we've warned that "-l" is going away. But the warning text > is primarily aimed at people who _meant_ to use "-l", as in > "git branch -l foo". People who mistakenly said "git branch > -l" may b

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

On Fri, May 25, 2018 at 10:55:45AM +0900, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > Hmm, actually, I suppose the true value of the warning is to help people > > doing "git branch -l foo", and it would still work there. The "more >

Re: [PATCH] branch: issue "-l" deprecation warning after pager starts

Jeff King <p...@peff.net> writes: > Hmm, actually, I suppose the true value of the warning is to help people > doing "git branch -l foo", and it would still work there. The "more > extreme" from your suggested patch would only affect "branch -l".

[PATCH] branch: issue "-l" deprecation warning after pager starts

On Thu, May 24, 2018 at 03:22:14PM -0400, Jeff King wrote: > On Thu, May 24, 2018 at 08:40:18PM +0530, Kaartic Sivaraam wrote: > > > > On the other hand, I'm not sure this is that big a deal. The point of > > > the deprecation warning is to catch people who are actually

Re: [PATCH] refspec.h: reinstate 'extern' to fix sparse warning

On Wed, 16 May 2018, Stefan Beller wrote: > On Wed, May 16, 2018 at 2:42 PM, Brandon Williams wrote: > > > Though now I'm confused, I thought we were going towards eliminating > > using the extern keyword? ...of course I guess it means something > > _slightly_ different when

Re: [PATCH] refspec.h: reinstate 'extern' to fix sparse warning

On Wed, May 16, 2018 at 2:42 PM, Brandon Williams wrote: > On 05/16, Ramsay Jones wrote: >> >> Signed-off-by: Ramsay Jones >> --- >> >> Hi Brandon, >> >> If you need to re-roll your 'bw/refspec-api' branch, could you please >> squash this, or the

Re: [PATCH] refspec.h: reinstate 'extern' to fix sparse warning

On 05/16, Ramsay Jones wrote: > > Signed-off-by: Ramsay Jones > --- > > Hi Brandon, > > If you need to re-roll your 'bw/refspec-api' branch, could you please > squash this, or the equivalent change before the 'struct refname' to > 'struct refname_item' name change,

[PATCH] refspec.h: reinstate 'extern' to fix sparse warning

Signed-off-by: Ramsay Jones --- Hi Brandon, If you need to re-roll your 'bw/refspec-api' branch, could you please squash this, or the equivalent change before the 'struct refname' to 'struct refname_item' name change, into the relevant patch. (which would be patch

[PATCH] commit: fix sparse 'not declared' warning

Signed-off-by: Ramsay Jones --- Hi Duy, If you need to re-roll your 'nd/commit-util-to-slab' branch, could you please squash this into the relevant patch (commit 37de2f0a93, "merge: use commit-slab in merge remote desc instead of commit->util", 2018-05-13). Also,

[PATCH] BUG_exit_code: fix sparse "symbol not declared" warning

Signed-off-by: Ramsay Jones --- Hi Johannes, If you need to re-roll your 'js/use-bug-macro' branch, could you please squash this into the relevant patch (commit a86303cb5d, "test-tool: help verifying BUG() code paths", 2018-05-02). This will, obviously, not be

[PATCH v2 16/18] branch-diff --dual-color: work around bogus white-space warning

_opt(o, DIFF_CONTEXT); + /* Avoid space-before-tab warning */ + if (c == ' ' && (len < 2 || line[1] == '\t' || +line[1] == '\r' || line[1] == '\n')) { +

[PATCH 16/18] branch-diff --dual-color: work around bogus white-space warning

_opt(o, DIFF_CONTEXT); + /* Avoid space-before-tab warning */ + if (c == ' ' && (len < 2 || line[1] == '\t' || +line[1] == '\r' || line[1] == '\n')) { +

Re: [PATCH] git-svn: avoid warning on undef readline()

Eric Wong writes: > Ævar Arnfjörð Bjarmason wrote: >> See https://public-inbox.org/git/86h8oobl36@phe.ftfl.ca/ for the >> original report. > > Thanks for taking a look at this. Also https://bugs.debian.org/894997 > >> --- a/perl/Git.pm >> +++ b/perl/Git.pm

Re: [PATCH] git-svn: avoid warning on undef readline()

cope of input record separator change", > 2016-10-14), but started warning due to the introduction of "use > warnings" to Git.pm in my f0e19cb7ce ("Git.pm: add the "use warnings" > pragma", 2018-02-25) released with 2.17.0. > > Since this functio

Re: [PATCH] git-svn: avoid warning on undef readline()

On Fri, Apr 06 2018, Eric Wong wrote: > Ævar Arnfjörð Bjarmason wrote: >> On Fri, Apr 06 2018, Eric Wong wrote: >> > Ævar Arnfjörð Bjarmason wrote: >> > >> >> --- a/perl/Git.pm >> >> +++ b/perl/Git.pm >> >> @@ -554,7 +554,7 @@ sub get_record { >> >> my

Re: [PATCH] git-svn: avoid warning on undef readline()

Ævar Arnfjörð Bjarmason wrote: > On Fri, Apr 06 2018, Eric Wong wrote: > > Ævar Arnfjörð Bjarmason wrote: > > > >> --- a/perl/Git.pm > >> +++ b/perl/Git.pm > >> @@ -554,7 +554,7 @@ sub get_record { > >>my ($fh, $rs) = @_; > >>local $/ = $rs; > >>my

Re: [PATCH] git-svn: avoid warning on undef readline()

On Fri, Apr 06 2018, Eric Wong wrote: > Ævar Arnfjörð Bjarmason wrote: >> See https://public-inbox.org/git/86h8oobl36@phe.ftfl.ca/ for the >> original report. > > Thanks for taking a look at this. Also https://bugs.debian.org/894997 > >> --- a/perl/Git.pm >> +++

Re: [PATCH] git-svn: avoid warning on undef readline()

Ævar Arnfjörð Bjarmason wrote: > See https://public-inbox.org/git/86h8oobl36@phe.ftfl.ca/ for the > original report. Thanks for taking a look at this. Also https://bugs.debian.org/894997 > --- a/perl/Git.pm > +++ b/perl/Git.pm > @@ -554,7 +554,7 @@ sub get_record { >

Re: [PATCH] git-svn: avoid warning on undef readline()

put record separator change", > 2016-10-14), but started warning due to the introduction of "use > warnings" to Git.pm in my f0e19cb7ce ("Git.pm: add the "use warnings" > pragma", 2018-02-25) released with 2.17.0. > > Since this function will

[PATCH] git-svn: avoid warning on undef readline()

Change code in Git.pm that sometimes calls chomp() on undef to only do so the value is defined. This code has been chomping undef values ever since it was added in b26098fc2f ("git-svn: reduce scope of input record separator change", 2016-10-14), but started warning due to the in

Re: [PATCH] fast-import: fix a sparse 'NULL pointer' warning

Ramsay Jones writes: > This was going to be an email to Jameson, but I wasn't fast enough! :( > > This was originally written against the 'pu' branch, but since the > 'jm/mem-pool' branch has graduated to 'next', I have rebased on 'next'. > > Perhaps this could be

[PATCH] fast-import: fix a sparse 'NULL pointer' warning

Commit a8dfa11562 ("fast-import: introduce mem_pool type", 2018-03-26) introduces a 'mem_pool' type, along with a file-local global symbol ('fi_mem_poll') which is initialised in its declaration. This causes sparse to issue a warning, thus: SP fast-import.c fast-import.c:301:4

Re: [PATCH 2/2] read-cache: fix an -Wmaybe-uninitialized warning

On Tue, Mar 20, 2018 at 10:52:16PM +, Ramsay Jones wrote: > > Maybe too clever, but I think you could just do: > > > > unsigned int saved_namelen = 0; > > ... > > saved_namelen = ce_namelen(ce); > > ... > > if (saved_namelen) > > ce->ce_namelen = saved_namelen; > >

Re: [PATCH 2/2] read-cache: fix an -Wmaybe-uninitialized warning

On 20/03/18 04:36, Jeff King wrote: > On Mon, Mar 19, 2018 at 05:56:11PM +, Ramsay Jones wrote: > [snip] >> diff --git a/read-cache.c b/read-cache.c >> index 2eb81a66b..49607ddcd 100644 >> --- a/read-cache.c >> +++ b/read-cache.c >> @@ -2104,13 +2104,15 @@ static int

Re: [PATCH 2/2] read-cache: fix an -Wmaybe-uninitialized warning

t; > /* block #3 */ > if (ce->ce_flags & CE_STRIP_NAME) { > ce->ce_namelen = saved_namelen; > ce->ce_flags &= ~CE_STRIP_NAME; > } > > The warning implies that gcc thinks it is possible that the first > block

[PATCH 2/2] read-cache: fix an -Wmaybe-uninitialized warning

The function ce_write_entry() uses a 'self-initialised' variable construct, for the symbol 'saved_namelen', to suppress a gcc '-Wmaybe-uninitialized' warning, given that the warning is a false positive. For the purposes of this discussion, the ce_write_entry() function has three code blocks

Re: [PATCH] http: fix an unused variable warning for 'curl_no_proxy'

On Wed, Mar 14, 2018 at 11:01:01PM +, Ramsay Jones wrote: > >> The version of libcurl installed was 0x070f04. So, while it was fresh in my > >> mind, I applied and tested this patch. > > > > Makes sense. This #if would go away under my "do not support antique > > curl versions" proposal. I

Re: [PATCH] http: fix an unused variable warning for 'curl_no_proxy'

earlier this evening >> and gcc complained, thus: >> >> CC http.o >> http.c:77:20: warning: ‘curl_no_proxy’ defined but not used >> [-Wunused-variable] >>static const char *curl_no_proxy; >> ^ >> The version of libcu

Re: [PATCH] http: fix an unused variable warning for 'curl_no_proxy'

On Wed, Mar 14, 2018 at 09:56:06PM +, Ramsay Jones wrote: > Signed-off-by: Ramsay Jones <ram...@ramsayjones.plus.com> > --- > > Hi Junio, > > I happened to be building git on an _old_ laptop earlier this evening > and gcc complained, thus: > > CC

Re: [PATCH] http: fix an unused variable warning for 'curl_no_proxy'

Hi, Ramsay Jones wrote: > Signed-off-by: Ramsay Jones <ram...@ramsayjones.plus.com> > --- > > Hi Junio, > > I happened to be building git on an _old_ laptop earlier this evening > and gcc complained, thus: > > CC http.o > http.c:77:20: warning:

[PATCH] http: fix an unused variable warning for 'curl_no_proxy'

Signed-off-by: Ramsay Jones <ram...@ramsayjones.plus.com> --- Hi Junio, I happened to be building git on an _old_ laptop earlier this evening and gcc complained, thus: CC http.o http.c:77:20: warning: ‘curl_no_proxy’ defined but not used [-Wunused-variable] static cons

[GSoC][PATCH 2/2] git-ci: update .pylintrc to ignore current warning

pylint's check for unused variables, global statements, redefined builtins, undefined loop variables, and unused imports are disabled. The current configuration allows git-p4.py to pass the check in Travis CI in my forked repository. Here is the link for the successful built:

[PATCH 0/2] sparse warning on next branch

Tonight's build had a sparse warning and an additional ./static-check.pl symbol appear on the 'next' branch. As you know, I like to catch these on the 'pu' branch before they graduate to 'next', but it seems that I missed these! :( (The 'pu' branch is quite noisy with regard to sparse and static

Re: Duplicate safecrlf warning for racily clean index entry

Matt McCutchen writes: > ... may be an important optimization.) If the line endings are changed > without changing the size or post-conversion content, then no unstaged > change is reported. It does not appear that git saves the pre- > conversion content. Correct. The

Re: Duplicate safecrlf warning for racily clean index entry

On Wed, 2018-02-21 at 08:53 +0100, Torsten Bögershausen wrote: > I don't hava a pointer, but what should happen ? > 2 warnings for 2 "git add" should be OK, I think. > > 1 warning is part of the optimization, that Git does to handle > hundrets and thousands of files effi

Re: Duplicate safecrlf warning for racily clean index entry

On Tue, 2018-02-20 at 08:42 -0500, Matt McCutchen wrote: > In either case, if "git update-index --refresh" (or "git status") is > run before "git add", then "git add" does not print the warning. On > the other hand, if line endings in the working

Re: Duplicate safecrlf warning for racily clean index entry

On Tue, Feb 20, 2018 at 08:42:26AM -0500, Matt McCutchen wrote: > I noticed that if a file subject to a safecrlf warning is added to the > index in the same second that it is created, resulting in a "racily > clean" index entry, then a subsequent "git add" command prin

Duplicate safecrlf warning for racily clean index entry

I noticed that if a file subject to a safecrlf warning is added to the index in the same second that it is created, resulting in a "racily clean" index entry, then a subsequent "git add" command prints another safecrlf warning. I reproduced this on the current "next"

[PATCH 2/2] Makefile: suppress a sparse warning for pack-revindex.c

Sparse has, for a long time, been issuing the following warning against the pack-revindex.c file: SP pack-revindex.c pack-revindex.c:64:23: warning: memset with byte count of 262144 This results from a unconditional check, with a hard-coded limit, which is really only appropriate

Re: [PATCH] Fixes compile warning with -Wimplicit-fallthrough CFLAGS

On Tue, Jan 23, 2018 at 10:33:57AM -0800, Junio C Hamano wrote: > Jeff King writes: > > >> diff --git a/apply.c b/apply.c > >> index 321a9fa68..a22fb2881 100644 > >> --- a/apply.c > >> +++ b/apply.c > >> @@ -1450,7 +1450,7 @@ static void recount_diff(const char *line, int size,

Re: [PATCH] Fixes compile warning with -Wimplicit-fallthrough CFLAGS

Jeff King writes: >> diff --git a/apply.c b/apply.c >> index 321a9fa68..a22fb2881 100644 >> --- a/apply.c >> +++ b/apply.c >> @@ -1450,7 +1450,7 @@ static void recount_diff(const char *line, int size, >> struct fragment *fragment) >> switch (*line) { >>

  1   2   3   4   5   6   7   8   9   10   >