Hi Johannes,
Le 04/10/2019 à 17:09, Johannes Schindelin via GitGitGadget a écrit :
> From: Johannes Schindelin
>
> MSVC would complain thusly:
>
> C4200: nonstandard extension used: zero-sized array in struct/union
>
> Let's just use the `FLEX_ARRAY` constant that we introduced for exactly
From: Johannes Schindelin
MSVC would complain thusly:
C4200: nonstandard extension used: zero-sized array in struct/union
Let's just use the `FLEX_ARRAY` constant that we introduced for exactly
this type of scenario.
Signed-off-by: Johannes Schindelin
---
compat/winansi.c | 2 +-
1 file
From: Johannes Schindelin
MSVC would complain thusly:
C4200: nonstandard extension used: zero-sized array in struct/union
Let's just use the `FLEX_ARRAY` constant that we introduced for exactly
this type of scenario.
Signed-off-by: Johannes Schindelin
---
compat/winansi.c | 2 +-
1 file
From: Johannes Schindelin
MSVC would complain thusly:
C4200: nonstandard extension used: zero-sized array in struct/union
Let's just use the `FLEX_ARRAY` constant that we introduced for exactly
this type of scenario.
Signed-off-by: Johannes Schindelin
---
compat/winansi.c | 2 +-
1 file
On Tue, Sep 24, 2019 at 05:34:08PM -0400, Jeff King wrote:
> > I'm tacking this patch on since this warning didn't show up until I
> > compiled it on gcc 9.1.0.
>
> Curiously, I _don't_ see the warning with gcc 9.2.1. By my reading of
> the manpage, this s
On Tue, Sep 24, 2019 at 02:08:53AM -0700, Denton Liu wrote:
> When we ran `make hdr-check`, we got the following warning on Arch Linux:
>
> pack-bitmap.h:20:19: error: ‘BITMAP_IDX_SIGNATURE’ defined but not used
> [-Werror=unused-const-variable=]
> 20 | st
When we ran `make hdr-check`, we got the following warning on Arch Linux:
pack-bitmap.h:20:19: error: ‘BITMAP_IDX_SIGNATURE’ defined but not used
[-Werror=unused-const-variable=]
20 | static const char BITMAP_IDX_SIGNATURE[] = {'B', &#
This is done by removing namelen at all. It is only used once
and simply strlen(name), hence we use strlen(name) directly.
Suggested-by: Jeff King
Signed-off-by: Stephan Beyer
---
t/helper/test-read-cache.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/t/helper/test-r
gcc 9.2.1 with -flto shows a maybe-uninitialized warning for index_pos
in builtin/pack-objects.c's add_object_entry(). Tracking it down,
the variable should be initialized in pack_objects.c's packlist_find().
The return value of locate_object_entry_hash(), which becomes index_pos,
is
On 8/25/2019 1:44 PM, René Scharfe wrote:
Let warning() format the message instead of using an intermediate strbuf
for that. This is shorter, easier to read and avoids an allocation.
Signed-off-by: René Scharfe
---
trace2/tr2_dst.c | 9 ++---
1 file changed, 2 insertions(+), 7
Taylor Blau writes:
> ... My patch has a few
> more details such as blame information (and how the typo was only made
> in the explicit version, not the variadic form), so it may be worthwhile
> to take that instead of this, but I don't mind either way.
Yup, that was exactly why I took that vers
> On Aug 26, 2019, at 11:33 AM, Jeff King wrote:
>
> On Mon, Aug 26, 2019 at 09:24:10AM -0700, Junio C Hamano wrote:
>
>> "Andrey Portnoy via GitGitGadget" writes:
>>
>>> Previously sprintf was the argument to the BANNED macro, where vsprintf is
>>> expected.
>>
>> Good eyes. Thanks.
>
>
> On Aug 26, 2019, at 11:33 AM, Jeff King wrote:
>
> On Mon, Aug 26, 2019 at 09:24:10AM -0700, Junio C Hamano wrote:
>
>> "Andrey Portnoy via GitGitGadget" writes:
>>
>>> Previously sprintf was the argument to the BANNED macro, where vsprintf is
>>> expected.
>>
>> Good eyes. Thanks.
>
>
On Mon, Aug 26, 2019 at 02:33:17PM -0400, Jeff King wrote:
> On Mon, Aug 26, 2019 at 09:24:10AM -0700, Junio C Hamano wrote:
>
> > "Andrey Portnoy via GitGitGadget" writes:
> >
> > > Previously sprintf was the argument to the BANNED macro, where vsprintf is
> > > expected.
> >
> > Good eyes. Than
On Mon, Aug 26, 2019 at 09:24:10AM -0700, Junio C Hamano wrote:
> "Andrey Portnoy via GitGitGadget" writes:
>
> > Previously sprintf was the argument to the BANNED macro, where vsprintf is
> > expected.
>
> Good eyes. Thanks.
There's an identical patch in:
https://public-inbox.org/git/cab
"Andrey Portnoy via GitGitGadget" writes:
> Previously sprintf was the argument to the BANNED macro, where vsprintf is
> expected.
Good eyes. Thanks.
>
> Andrey Portnoy (1):
> banned.h: fix vsprintf warning
>
> banned.h | 2 +-
> 1 file changed, 1 inse
From: Andrey Portnoy
Previously sprintf was the argument to the BANNED macro, where vsprintf
is expected.
Signed-off-by: Andrey Portnoy
---
banned.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/banned.h b/banned.h
index 447af24807..60a18d4403 100644
--- a/banned.h
+++ b/
Previously sprintf was the argument to the BANNED macro, where vsprintf is
expected.
Andrey Portnoy (1):
banned.h: fix vsprintf warning
banned.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
base-commit: 75b2f01a0f642b39b0f29b6218515df9b5eb798e
Published-As:
https://github.com
Let warning() format the message instead of using an intermediate strbuf
for that. This is shorter, easier to read and avoids an allocation.
Signed-off-by: René Scharfe
---
trace2/tr2_dst.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/trace2/tr2_dst.c b/trace2
Now that we're confident our pax extended header calculation is correct,
turn the criticality of the assertion up to the maximum, from warning
right up to BUG. Simplify the test, as the stderr comparison step would
not be reached in case the BUG message is triggered.
Signed-off-by: René Sc
Cast the evaluated value of the macro INITIAL_LOCK to void to instruct
the compiler that we're not interested in said value nor the following
warning:
In file included from compat/nedmalloc/nedmalloc.c:63:
compat/nedmalloc/malloc.c.h: In function ‘init_user_mstate’:
compat/nedmalloc/mallo
On Thu, Jul 18, 2019 at 02:07:23PM -0700, Junio C Hamano wrote:
> >> + git rm qfwfq >msg &&
> >> + test_i18ngrep ! "needs merge" msg &&
> >
> > Should we capture stderr from "git rm", too, to cover all bases?
>
> Do you mean
>
> git rm blob >msg 2>&1
>
> because we could later change ou
Jeff King writes:
>> +test_expect_success 'Resolving by removal is not a warning-worthy event' '
>> +git reset -q --hard &&
>> +test_when_finished "rm -f .git/index.lock msg && git reset -q --hard" &&
>> +qfw
mit", "git describe", etc. to
> squelch the message.
Nicely explained, and the patch makes sense.
> +test_expect_success 'Resolving by removal is not a warning-worthy event' '
> + git reset -q --hard &&
> + test_when_finished "
it a/t/t3600-rm.sh b/t/t3600-rm.sh
index b8fbdefcdc..5aae78ccc4 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -251,6 +251,19 @@ test_expect_success 'choking "git rm" should not let it
die with cruft' '
test_path_is_missing .git/index.lock
'
+test_expect_succ
In the previous patch, we added a deprecation warning for the current
log.mailmap setting. This warning only appears when git is attached to
a controlling terminal. Some tests however run under an emulated
terminal, so we need to disable the warning for those tests.
Thanks to Junio for suggesting
Based on discussions around changing the log.mailmap default to being
enabled, it was decided that a transitional period is required.
Accordingly, we announce this transitional period with a warning
message.
Signed-off-by: Ariadne Conill
---
builtin/log.c | 26 --
1
Ariadne Conill writes:
> In the previous patch, we added a deprecation warning for the current
> log.mailmap setting. This warning only appears when git is attached to
> a controlling terminal. Some tests however run under an emulated
> terminal, so we need to disable the warning for
Ariadne Conill writes:
> + if (mailmap < 0) {
> + /*
> + * Only display the warning if the session is interactive
> + * and pretty_given is false. We determine that the session
> + * is interactive by checking if aut
In the previous patch, we added a deprecation warning for the current
log.mailmap setting. This warning only appears when git is attached to
a controlling terminal. Some tests however run under an emulated
terminal, so we need to disable the warning for those tests.
Signed-off-by: Ariadne Conill
Based on discussions around changing the log.mailmap default to being
enabled, it was decided that a transitional period is required.
Accordingly, we announce this transitional period with a warning
message.
Signed-off-by: Ariadne Conill
---
builtin/log.c | 25 -
1 file
Based on discussions around changing the log.mailmap default to being
enabled, it was decided that a transitional period is required.
Accordingly, we announce this transitional period with a warning
message.
Signed-off-by: Ariadne Conill
---
builtin/log.c | 17 -
1 file changed
Hi Ramsay,
On Thu, Jun 27, 2019 at 12:14 AM Ramsay Jones
wrote:
>
> If you need to re-roll your 'cc/multi-promisor' branch, could you please
> squash this into the relevant patch (commit 9e27beaa23, "promisor-remote:
> implement promisor_remote_get_direct()", 2019-06-25).
Sure, I have integrated
Signed-off-by: Ramsay Jones
---
Hi Christian,
If you need to re-roll your 'cc/multi-promisor' branch, could you please
squash this into the relevant patch (commit 9e27beaa23, "promisor-remote:
implement promisor_remote_get_direct()", 2019-06-25).
[No, this is not the same as the April patch!
From: Johannes Schindelin
MS Visual C suggests that the construct
condition ? (int) i : (ptrdiff_t) d
is incorrect. Let's fix this by casting to ptrdiff_t also for the
positive arm of the conditional.
Signed-off-by: Johannes Schindelin
---
compat/obstack.h | 2 +-
1 file changed, 1 i
Signed-off-by: Ramsay Jones
---
Hi Duy,
If you need to re-roll your 'nd/index-dump-in-json' branch, could
you please squash this into the relevant patch (commit 53f1666b3a,
'split-index.c: dump "link" extension as json', 2019-06-19).
Thanks!
ATB,
Ramsay Jones
json-writer.h | 1 +
1 file ch
From: Johannes Schindelin
MS Visual C suggests that the construct
condition ? (int) i : (ptrdiff_t) d
is incorrect. Let's fix this by casting to ptrdiff_t also for the
positive arm of the conditional.
Signed-off-by: Johannes Schindelin
---
compat/obstack.h | 2 +-
1 file changed, 1 i
From: Johannes Schindelin
MS Visual C suggests that the construct
condition ? (int) i : (ptrdiff_t) d
is incorrect. Let's fix this by casting to ptrdiff_t also for the
positive arm of the conditional.
Signed-off-by: Johannes Schindelin
---
compat/obstack.h | 2 +-
1 file changed, 1 i
I just used git-send-email the first time since ages. When it finished,
I saw a stream of 16 warnings:
Warning: unable to close filehandle properly: Bad file descriptor during
global destruction.
The invocation was this:
git send-email --to git@vger.kernel.org patches
where the argument
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
Signed-off-by: Derrick Stolee
---
advice.c| 2 ++
advice.h| 1 +
wt-status.c | 17 +
3 files changed, 20 insertions(+)
diff --git a/advice.c b/advice.c
index ce5f374ecd..54f8dea30c 100644
--- a/advice.c
+++ b/advice.
On Mon, Jun 03, 2019 at 08:06:54AM +0200, Ulrich Windl wrote:
> > Imagine you have only v1.0.0 (which is with known issues) but
> > somebody did "cd .git/refs/tags && mv v1.0.0 v1.1.0" in an attempt
> > to fool you. The fact that your 'master' is a bit ahead of the
> > commit that was tagged with
>>> Junio C Hamano schrieb am 29.05.2019 um 20:01 in
Nachricht
:
> "Ulrich Windl" writes:
>
>> So I got the response:
>> warning: tag 'isredir‑0.3.0' is really 'iredir‑0.3.0' here
>> isredir‑0.3.0‑3‑gaf467c7
>
> I suspect th
"Ulrich Windl" writes:
> So I got the response:
> warning: tag 'isredir-0.3.0' is really 'iredir-0.3.0' here
> isredir-0.3.0-3-gaf467c7
I suspect that "git cat-file tag isredir-0.3.0" would begin like
$ git cat-file tag iredir-0.3.0
mple) "git describe --always --tags
af467c7".
So I got the response:
warning: tag 'isredir-0.3.0' is really 'iredir-0.3.0' here
isredir-0.3.0-3-gaf467c7
I'm unsure what the message is actually saying: The hash cannot be resolved in
a unique way?
I just see
In function 'finish_request',
inlined from 'process_response' at http-push.c:248:2:
http-push.c:587:4: warning: '%s' directive argument is null [-Wformat-overflow=]
587 |fprintf(stderr, "Unable to get pack file %s\n%s",
|^~~
Eric Sunshine writes:
>> if (request->curl_result != CURLE_OK) {
>> fprintf(stderr, "Unable to get pack file %s\n%s",
>> - request->url, curl_errorstr);
>> + request->url ? request->url : "",
>> +
On Fri, May 10, 2019 at 2:59 AM Carlo Marcelo Arenas Belón
wrote:
> In function 'finish_request',
> inlined from 'process_response' at http-push.c:248:2:
> http-push.c:587:4: warning: '%s' directive argument is null
> [-Wformat-overflow=]
> 587
In function 'finish_request',
inlined from 'process_response' at http-push.c:248:2:
http-push.c:587:4: warning: '%s' directive argument is null [-Wformat-overflow=]
587 |fprintf(stderr, "Unable to get pack file %s\n%s",
|^~~
Christian Couder writes:
> Hi Ramsay,
>
> On Thu, Apr 4, 2019 at 8:59 PM Ramsay Jones
> wrote:
>
>> If you need to re-roll your 'cc/multi-promisor' branch, could you
>> please squash this into the relevant patch (commit e52d417b57
>> ("promisor-remote: implement promisor_remote_get_direct()", 2
Hi Ramsay,
On Thu, Apr 4, 2019 at 8:59 PM Ramsay Jones wrote:
> If you need to re-roll your 'cc/multi-promisor' branch, could you
> please squash this into the relevant patch (commit e52d417b57
> ("promisor-remote: implement promisor_remote_get_direct()", 2019-04-01)).
>
> [I had a deja-vu momen
Signed-off-by: Ramsay Jones
---
Hi Christian,
If you need to re-roll your 'cc/multi-promisor' branch, could you
please squash this into the relevant patch (commit e52d417b57
("promisor-remote: implement promisor_remote_get_direct()", 2019-04-01)).
[I had a deja-vu moment writing this - it see
The "git reflog expire" command when given an unknown reference has
since 4264dc15e1 ("git reflog expire", 2006-12-19) when this command
was implemented emit an error, but this has never been tested for.
Let's test for it, also under gc.reflogExpire{Unreachable,}=never in
case a future change is t
it? Didn't on clang/gcc, but then again it's
> just-as-valid-C & just a style issue, so compilers don't care...
This is a 'sparse' warning (see subject line). :-D
I run the 'sparse' Makefile target on each branch and save to
a file, sp-out, nsp-out
On Sat, Mar 23 2019, Ramsay Jones wrote:
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Ævar,
>
> If you need to re-roll your 'ab/commit-graph-fixes' branch, could you
> please squash this into the relevant patch (commit aeb244adbc
> ("commit-graph: don't early exit(1) on e.g. \"git status\"", 2019
gt;
> But if I do this:
>
> $ echo "docs/themes/*/.git >> .gitexcludes
> $ git config core.excludeFiles .gitexcludes
> $ git add docs
> warning: adding embedded git repository: docs/themes/foo
>
> It seems to me that this goes against what the git-add(1) man pa
excludes
$ git config core.excludeFiles .gitexcludes
$ git add docs
warning: adding embedded git repository: docs/themes/foo
It seems to me that this goes against what the git-add(1) man page says.
A workaround I found on stackoverflow is to add any file within the target
directory:
$ git add docs/themes/foo
Signed-off-by: Ramsay Jones
---
Hi Ævar,
If you need to re-roll your 'ab/commit-graph-fixes' branch, could you
please squash this into the relevant patch (commit aeb244adbc
("commit-graph: don't early exit(1) on e.g. \"git status\"", 2019-02-21).
This same commit (aeb244adbc) also removes the
The "git reflog expire" command when given an unknown reference has
since 4264dc15e1 ("git reflog expire", 2006-12-19) when this command
was implemented emit an error, but this has never been tested for.
Let's test for it, also under gc.reflogExpire{Unreachable,}=never in
case a future change is t
Signed-off-by: Ramsay Jones
---
Hi Christian,
If you need to re-roll your 'cc/multi-promisor' branch, could you
please squash this into the relevant patch (commit 9e8a7cf4be
("promisor-remote: implement promisor_remote_get_direct()", 2019-03-12)).
Also, I note that the promisor_remote_new() f
Signed-off-by: Ramsay Jones
---
Hi Jonathan,
If you need to re-roll your 'jt/fetch-cdn-offload' branch, could you
please squash this into the relevant patch (commit 0e821b4427
("upload-pack: send part of packfile response as uri", 2019-02-23)).
Thanks!
ATB,
Ramsay Jones
upload-pack.c | 2 +
>> please squash this into the relevant patch (commit 4478671442,
>> "cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS switch", 2019-01-12).
>>
>> [the warning is caused by the lack of the extern declaration of the
>> 'the_index' symbol.]
>
> I
che.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS switch", 2019-01-12).
>
> [the warning is caused by the lack of the extern declaration of the
> 'the_index' symbol.]
Is it a false alarm? The variable is actually defined in this file now
which should also function as a declaration, y
Signed-off-by: Ramsay Jones
---
Hi Duy,
If you need to re-roll your 'nd/the-index-final' branch, could you
please squash this into the relevant patch (commit 4478671442,
"cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS switch", 2019-01-12).
[the warning is caused by th
Hello!
As you may have noticed, I sent you an email from your account.
This means that I have full access to your account: On moment of hack your
account has password: ever
You say: this is the old password!
Or: I will change my password at any time!
Yes! You're right!
But the fact is that whe
Duy Nguyen writes:
> I have a better plan: stop exposing parse-options loop to outside.
> What all these commands need is the ability to deal with unknown
> options (or non-options in update-index case). They could register
> callbacks to deal with those and keep calling parse_options() instead.
On Tue, Dec 11, 2018 at 3:13 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > The reason it's in parse_options_step() is because -h is also handled
> > in there. Although -h does not bury exit() deep in the call chain. So
> > how about this as a replacement?
>
> So just like -h returns PARSE
The compiler reports this because show_gitcomp() never actually
returns a value:
"parse-options.c", line 520: warning: Function has no return
statement : show_gitcomp
We could shut the compiler up. But instead let's not bury exit() too
deep. Do the same as internal -h han
Duy Nguyen writes:
> The reason it's in parse_options_step() is because -h is also handled
> in there. Although -h does not bury exit() deep in the call chain. So
> how about this as a replacement?
So just like -h returns PARSE_OPT_HELP and causes the calling
parse_options() to exit(129), the ne
On Mon, Dec 10, 2018 at 03:36:54PM +0900, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> > The compiler reports this because show_gitcomp() never actually
> > returns a value:
> >
> > "parse-options.c", line 520: warning: Function has no
Nguyễn Thái Ngọc Duy writes:
> The compiler reports this because show_gitcomp() never actually
> returns a value:
>
> "parse-options.c", line 520: warning: Function has no return
> statement : show_gitcomp
>
> The function calls exit() and will n
The compiler reports this because show_gitcomp() never actually
returns a value:
"parse-options.c", line 520: warning: Function has no return
statement : show_gitcomp
The function calls exit() and will never return. Update and mark it
NORETURN.
Reported-by: Ævar Arnfjörð
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 be i
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
s
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 r
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 scr
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
> writ
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, but
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/e
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 Junio
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 's
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 wit
uct load_index_extensions' 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
_index_extensions' 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 (un
th 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-by: Ramsay Jones
---
Hi Ben,
If you need to re-roll your 'bp/rea
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 d
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 comp
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 FreeB
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 older
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, revis
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/gitgitg
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
1 - 100 of 780 matches
Mail list logo
