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
>
Æ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
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
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
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
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
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
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
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
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
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
>
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,
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(+),
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
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
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
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
>>>
' 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
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
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
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
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
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
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
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,
: 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
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
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
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
"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 &&
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
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
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
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
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
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
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
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
, DIFF_CONTEXT);
+ /* Avoid space-before-tab warning */
+ if (c == ' ' && (len < 2 || line[1] == '\t' ||
+line[1] == '\r' || line[1] == '\n')) {
+
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
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
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
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
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
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");
> >> -
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
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");
>> -
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,
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");
> -
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
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
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
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
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
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
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.
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
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
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) {
>> +
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
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
>
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".
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
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
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
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,
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
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,
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
_opt(o, DIFF_CONTEXT);
+ /* Avoid space-before-tab warning */
+ if (c == ' ' && (len < 2 || line[1] == '\t' ||
+line[1] == '\r' || line[1] == '\n')) {
+
_opt(o, DIFF_CONTEXT);
+ /* Avoid space-before-tab warning */
+ if (c == ' ' && (len < 2 || line[1] == '\t' ||
+line[1] == '\r' || line[1] == '\n')) {
+
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
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
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
Æ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
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
>> +++
Æ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 {
>
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
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
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
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
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;
> >
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
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
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
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
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
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
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:
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
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:
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
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
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
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
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
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"
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
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,
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 - 100 of 1219 matches
Mail list logo