Junio C Hamano wrote:
> I'd actually see this as Gerrit being weird.
>
> If it wants to quarantine a commit destined to the "master" branch,
> couldn't it just let people push to "master" and then internally
> update "for/master" instead?
It is because pushing doesn't update refs/heads/master. I
2013/2/8 Torsten Bögershausen :
> On 08.02.13 03:10, Jiang Xin wrote:
>> + /* If no error occurs, returns columns really required with
>> utf8_strwidth. */
>> + if (0 <= columns)
>> + columns = utf8_strwidth(buf.buf);
>> + strbuf_release(&buf);
>> + return columns;
>> +
This new configuration variable overrides the remote in
`branch..remote` for pushes. It is useful in the typical
scenario, where the remote I'm pulling from is not the remote I'm
pushing to. Although `remote..pushurl` is similar, it does not
serve the purpose as the URL would lack corresponding r
Junio C Hamano writes:
> I think the triangle
> arrangement where you want to have "this is where I fetch from and
> integrate with, and that is where I publish" is more common among
> the Git users these days.
Another thing to know about is that the recent move to change the
behaviour of
On Thu, Feb 07, 2013 at 10:08:48PM -0800, Junio C Hamano wrote:
> How best to express the triangle is somewhat tricky, but I think it
> is sensible to say you have "origin" that points to your upstream
> (i.e. me), and "peff" that points to your publishing point, in other
> words, make it explicit
On Wed, Feb 6, 2013 at 9:27 PM, R. Diez wrote:
> Hi there:
>
> I asked a few days ago whether I could easily diff 2 file revisions with the
> mouse in gitk, but I got no reply yet, see here:
>
>
>How to diff two file revisions with the mouse (with gitk)
>https://groups.google.com/forum/#!
On Tue, Feb 05, 2013 at 07:38:58PM -0500, Ted Zlatanov wrote:
> Add Git credential helper that can parse netrc/authinfo files.
>
> This credential helper supports multiple files, returning the first one
> that matches. It checks file permissions and owner. For *.gpg files,
> it will run GPG to
Ted Zlatanov writes:
> I agree this Makefile is not a good test to ship out. It was my quickie
> test rig that I should have reworked before adding to the patch. Sorry.
Nothing to be sorry about. Starting with quick-and-dirty and
polishing for public consumption is what the review cycle is ab
(Sorry for confusing: I should have written:)
Please see below for specifications on fputs()
Linux:
RETURN VALUE
fputc(), putc() and putchar() return the character written as an unsigned char
cast to an int or EOF on error.
puts() and fputs() return a nonnegative number on success, or EOF on err
Jeff King writes:
> On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:
>
>> This has been annoying me for a really long time, but I never really
>> got around to scratching this particular itch. I have a very common
>> scenario where I fork a project on GitHub. I have two con
On 07.02.13 20:35, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> Torsten Bögershausen wrote:
>>> t0070 and t1301 fail when running the test suite under cygwin.
>>> Skip the failing tests by unsetting POSIXPERM.
>> t1301 does not fail for me. (WIN XP (SP3) on NTFS)
> Others run Cygwin with vfat
On 08.02.13 03:10, Jiang Xin wrote:
> Since command usages can be translated, they may not align well especially
> when they are translated to CJK. A wrapper utf8_fprintf can help to return
> the correct columns required.
>
> Signed-off-by: Jiang Xin
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
>
On Thu, Feb 07, 2013 at 03:01:20PM +0100, Michal Nazarewicz wrote:
> > There are a few disallowed characters, like "\n" in key or value, and
> > "=" in a key. They should never happen unless the caller is buggy, but
> > should we check and catch them here?
>
> I left it as is for now since it
On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:
> This has been annoying me for a really long time, but I never really
> got around to scratching this particular itch. I have a very common
> scenario where I fork a project on GitHub. I have two configured
> remotes: origin
On Thu, Feb 07, 2013 at 11:24:28PM -0500, Jeff King wrote:
> Should you be dropping most of the comment like this? I would expect it
> to be more like:
>
> We have to restrict this trick to gcc, though, because we do not
> assume all compilers support variadic macros. But since...
I'll submit
On Thu, Feb 07, 2013 at 11:28:31AM -0800, Junio C Hamano wrote:
> Matthieu Moy writes:
>
> > The configuration of the install directory is not reused from the
> > toplevel Makefile: we assume Git is already built, hence just call
> > "git --exec-path". This avoids too much surgery in the topleve
On Thu, Feb 07, 2013 at 01:30:32PM -0800, Matt Kraai wrote:
> From: Matt Kraai
>
> QNX 6.3.2 uses GCC 2.95.3 by default, and GCC 2.95.3 doesn't remove the
> comma if the error macro's variable argument is left out.
>
> Instead of testing for a sufficiently recent version of GCC, make
> __VA_ARG
Signed-off-by: Nguyễn Thái Ngọc Duy
---
We may do some redundant stat() here, but I don't think it can slow
count-objects down much to worry about.
Documentation/git-count-objects.txt | 2 ++
builtin/count-objects.c | 29 ++---
2 files changed, 20 insertio
prepare_packed_git_one() is modified to allow count-objects to hook a
report function to so we don't need to duplicate the pack searching
logic in count-objects.c. When report_pack_garbage is NULL, the
overhead is insignificant.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-count-obj
The current description requires a bit of guessing (what clause
corresponds to what printed line?) and lacks information, such as
the unit of size and size-pack.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-count-objects.txt | 20 +++-
1 file changed, 15 insertions(+
This series:
- updates count-objects -v documentation, describe each line in detail
- counts garbage files in pack directory in addition to loose odb
- shows how much disk space consumed by garbage files
Nguyễn Thái Ngọc Duy (3):
git-count-objects.txt: describe each line in -v output
count-
Since command usages can be translated, they may not align well especially
when they are translated to CJK. A wrapper utf8_fprintf can help to return
the correct columns required.
Signed-off-by: Jiang Xin
Signed-off-by: Nguyễn Thái Ngọc Duy
---
parse-options.c | 5 +++--
utf8.c | 22 +
On Thu, 07 Feb 2013 15:52:41 -0800 Junio C Hamano wrote:
>> +@echo "=> Look for any entry in the default file set"
>> +echo "" | ./git-credential-netrc -d -v get
>> +@echo "=> Look for github.com in the default file set"
>> +echo "host=google.com" | ./git-credential-netrc -d -v g
On Fri, Feb 08 2013, Junio C Hamano wrote:
> I'd actually be more worried about the error checking issue
> Peff raised during his review. I have a feeling that "when in doubt,
> do not cause harm" is a more prudent way to go than "I do not know,
> so I'll let anything pass".
I can implement whate
Before this change, if git-mergetool was invoked with regard to
files with a percent sign (%) in their names, it would print an
error. For example, if you were calling mergetool on a file called
"%2F":
printf: %2F: invalid directive
This changes the behavior to pass "%s" to printf as its firs
The latest maintenance release Git v1.8.1.3 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
29ed9047263f9835726200226451339276641779 git-1.8.1.3.tar.gz
6b1e57bde2f2b0a86532390c15bfa7b18
On Fri, Feb 8, 2013 at 1:12 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> I thought about that, but we may need to do extra stat() for loose
>> garbage as well. As it is now, garbage is complained loudly, which
>> gives me enough motivation to clean up, even without looking at how
>> much d
Ted Zlatanov writes:
> Add Git credential helper that can parse netrc/authinfo files.
I think this line is redundant; we already know it on the Subject: line.
> This credential helper supports multiple files, returning the first one
> that matches. It checks file permissions and owner. For *.
Jonathan Nieder writes:
> The usual incantation is "git push gerrit HEAD:refs/for/master". Is
> the code review creation push that uses a different branchname from
> the branch the integrator pulls what seems backward, or is it the need
> to specify a refname at all on the command line?
>
> I ag
Matthieu Moy writes:
> Michal Nazarewicz writes:
>
>> From: Michal Nazarewicz
>>
>> Add a credential() function which is an interface to the git
>> credential command. The code is heavily based on credential_*
>> functions in .
>
> I'm no perl expert, so I cannot comment much on style (there a
Hi Ram,
Ramkumar Ramachandra wrote:
> And yes, a regular `git push origin refs/for/master` is just retarded.
The usual incantation is "git push gerrit HEAD:refs/for/master". Is
the code review creation push that uses a different branchname from
the branch the integrator pulls what seems backwar
From: Matt Kraai
QNX 6.3.2 uses GCC 2.95.3 by default, and GCC 2.95.3 doesn't remove the
comma if the error macro's variable argument is left out.
Instead of testing for a sufficiently recent version of GCC, make
__VA_ARGS__ match all of the arguments.
Signed-off-by: Matt Kraai
---
git-compat
On Thu, Feb 07, 2013 at 01:05:19PM -0800, Junio C Hamano wrote:
> Matt Kraai writes:
>
> > -#if defined(__GNUC__) && ! defined(__clang__)
> > -#define error(fmt, ...) (error((fmt), ##__VA_ARGS__), -1)
> > -#endif
> > +#define error(...) (error(__VA_ARGS__), -1)
>
> Before your change, we only de
On Thu, Feb 07, 2013 at 01:05:19PM -0800, Junio C Hamano wrote:
> Matt Kraai writes:
>
> > -#if defined(__GNUC__) && ! defined(__clang__)
> > -#define error(fmt, ...) (error((fmt), ##__VA_ARGS__), -1)
> > -#endif
> > +#define error(...) (error(__VA_ARGS__), -1)
>
> Before your change, we only de
Matt Kraai writes:
> -#if defined(__GNUC__) && ! defined(__clang__)
> -#define error(fmt, ...) (error((fmt), ##__VA_ARGS__), -1)
> -#endif
> +#define error(...) (error(__VA_ARGS__), -1)
Before your change, we only define error() macro for GCC variants,
but with your patch that no longer is the c
John Keeping writes:
> This series changes a couple of places that do not currently indent
> their output when being shown with a graph.
>
> The first patch was already posted [1] and addresses the output of "git
> log --graph -c -p". Patch 2 is an independent fix I noticed while
> working on th
When running "git log --graph --cc -p" the diff output for merges is not
indented by the graph structure, unlike the diffs of non-merge commits
(added in commit 7be5761 - diff.c: Output the text graph padding before
each diff line).
Fix this by teaching the combined diff code to output diff_line_p
This series changes a couple of places that do not currently indent
their output when being shown with a graph.
The first patch was already posted [1] and addresses the output of "git
log --graph -c -p". Patch 2 is an independent fix I noticed while
working on the later patches.
Patches 3-5 intr
This is a helper function to call the diff output_prefix function and
return its value as a C string, allowing us to greatly simplify
everywhere that needs to get the output prefix.
Signed-off-by: John Keeping
---
diff.c | 10 ++
diff.h | 3 +++
2 files changed, 13 insertions(+)
diff -
When showing merges in git-log, the same commit is shown once for each
parent. Combined with "--graph" this results in graph_show_commit()
being called once for each parent without graph_update() being called.
Currently graph_show_commit() does not print anything on subsequent
invocations for the
Write the prefix for an output line to the same file as the actual
content.
Signed-off-by: John Keeping
---
diff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/diff.c b/diff.c
index 348f71b..bf95235 100644
--- a/diff.c
+++ b/diff.c
@@ -4485,7 +4485,7 @@ void diff_flush(str
Signed-off-by: John Keeping
---
diff.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index bf95235..73ae02d 100644
--- a/diff.c
+++ b/diff.c
@@ -2123,7 +2123,8 @@ static unsigned char *deflate_it(char *data,
return deflated;
}
-static void em
Signed-off-by: John Keeping
---
diff.c | 115 -
1 file changed, 20 insertions(+), 95 deletions(-)
diff --git a/diff.c b/diff.c
index ed14d5d..f441f6c 100644
--- a/diff.c
+++ b/diff.c
@@ -402,12 +402,7 @@ static void emit_line_0(stru
Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra wrote:
>> And yes, a regular `git push origin refs/for/master` is just retarded.
>
> Actually a git config remote.origin.push refs/heads/*:refs/for/* makes
> more sense here.
Sorry about all that confusion. The first line should be `git push
orig
From: Matt Kraai
QNX 6.3.2 uses GCC 2.95.3 by default, and GCC 2.95.3 doesn't remove the
comma if the error macro's variable argument is left out.
Instead of testing for a sufficiently recent version of GCC, make
__VA_ARGS__ match all of the arguments. Since this should work on any
C99-complian
Tim Chase writes:
> ... I didn't
> see any sort of "pre-merge" hook script.
http://thread.gmane.org/gmane.comp.version-control.git/94111/focus=71069
I think yours is a canonical example of "I do not want to run
command X when these conditions hold", when "these conditions" can
be checked local
Ramsay Jones writes:
> Torsten Bögershausen wrote:
>> t0070 and t1301 fail when running the test suite under cygwin.
>> Skip the failing tests by unsetting POSIXPERM.
>
> t1301 does not fail for me. (WIN XP (SP3) on NTFS)
Others run Cygwin with vfat or some other filesystem, and some of
them do
Matthieu Moy writes:
> The configuration of the install directory is not reused from the
> toplevel Makefile: we assume Git is already built, hence just call
> "git --exec-path". This avoids too much surgery in the toplevel Makefile.
>
> git-remote-mediawiki.perl can now "use Git;".
>
> Signed-of
Matthieu Moy writes:
> Similarly to the extraction of perl-related code in perl.mak, we extract
> general default configuration from the Makefile to make it available from
> directories other than the toplevel.
>
> This is required to make perl.mak usable because it requires $(pathsep)
> to be se
Matthieu Moy writes:
> The final goal is to make it easy to write Git commands in perl in the
> contrib/ directory. It is currently possible to do so, but without the
> benefits of Git's Makefile: adapt first line with $(PERL_PATH),
> hardcode the path to Git.pm, ...
>
> We make the perl-related
[tried IRC to no avail]
I've been trying to find a way to prevent myself from merging a
client-specific branch back into my dev/master branches. Is there an
easy/straightforward way to do this (perhaps via a hook)? I didn't
see any sort of "pre-merge" hook script. Visualized:
A -> B -> C [dev
Michal Nazarewicz writes:
> From: Michal Nazarewicz
>
> Add a credential() function which is an interface to the git
> credential command. The code is heavily based on credential_*
> functions in .
I'm no perl expert, so I cannot comment much on style (there are many
small changes compared to
Michal Nazarewicz writes:
> From: Michal Nazarewicz
>
> If smtp_user is provided but smtp_pass is not, instead of
> prompting for password, make git-send-email use git
> credential command instead.
>
> Signed-off-by: Michal Nazarewicz
> ---
Nice ;-)
I'd expect reviews on 4/5 from Peff and Mat
On Thu, 07 Feb 2013 10:23:20 -0800 Junio C Hamano wrote:
JCH> "Clear everything you saw so far" would be useful for variables
JCH> other than "credential.helper"; shouldn't it be done by adding a
JCH> general syntax to the configuration file format and teach the
JCH> configuration parser to clea
Torsten Bögershausen wrote:
> t0070 and t1301 fail when running the test suite under cygwin.
> Skip the failing tests by unsetting POSIXPERM.
t1301 does not fail for me. (WIN XP (SP3) on NTFS)
[It's so long since I looked, but I'm pretty sure that the failure
in t0070 is caused by *git*, not by cy
Jeff King writes:
> If the new client can handle the old-style server's response, then the
> server can start blasting out refs (optionally after a timeout) and stop
> when the client interrupts with "hey, wait, I can speak the new
> protocol". The server just has to include "you can interrupt me
Ted Zlatanov writes:
>> Below is current git message when a local config credential.helper has
>> an empty value. Please skip an empty value.
>
>> $ git push --force origin master
>> git: 'credential-' is not a git command. See 'git --help'.
>> Did you mean this?
>>credential
Why isn't "
Duy Nguyen writes:
> I thought about that, but we may need to do extra stat() for loose
> garbage as well. As it is now, garbage is complained loudly, which
> gives me enough motivation to clean up, even without looking at how
> much disk space it uses.
I wouldn't call a single line "garbage: 4"
Michael J Gruber writes:
>>> (cd t && git grep GET_SHA1_QUIETLY HEAD:../cache.h)
>>> ../HEAD:../cache.h:#define GET_SHA1_QUIETLY01
>>
>> Yuck.
>
> And even more yuck:
>
> (cd t && git grep --full-name GET_SHA1_QUIETLY HEAD:../cache.h)
> HEAD:../cache.h:#define GET_SHA1_QUIETLY01
On 02/07/2013 05:14 PM, Ramkumar Ramachandra wrote:
> This has been annoying me for a really long time, but I never really
> got around to scratching this particular itch. I have a very common
> scenario where I fork a project on GitHub. I have two configured
> remotes: origin which points to "g
Michael Haggerty writes:
> A first weakness of your proposal is that even though the hidden refs
> are (optionally) fetchable, there is *no* way to discover them remotely
> or to bulk-download them; they would have to be retrieved one by one
> using out-of-band information. And if I understand c
On Thu, 27 Oct 2011 12:05:03 -0400 John Szakmeister
wrote:
JS> Just wanted to keep folks in the loop. It turns out that the Secrets
JS> API is still to young. I asked about the format to store credentials
JS> in (as far as attributes), and got a response from a KDE developer
JS> that says it'
On Sat, 10 Nov 2012 23:12:50 +0800 乙酸鋰 wrote:
> In credential.c, line 67:
> if (!strcmp(key, "helper"))
> string_list_append(&c->helpers, value);
> In global config, I add one credential helper.
> But I do not want to use any credential helper in a specific repository.
> Currently t
On Thu, 07 Feb 2013 08:08:59 +0100 Matthieu Moy
wrote:
MM> Plus, read/write has already been used for a while in the C API, so I'd
MM> rather keep the same names for the Perl equivalent.
That makes perfect sense.
Ted
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod
From: Michal Nazarewicz
If smtp_user is provided but smtp_pass is not, instead of
prompting for password, make git-send-email use git
credential command instead.
Signed-off-by: Michal Nazarewicz
---
Documentation/git-send-email.txt | 4 +--
git-send-email.perl | 59 ++
From: Michal Nazarewicz
The command_close_bidi_pipe() function will insist on closing both
input and output pipes returned by command_bidi_pipe(). With this
change it is possible to close one of the pipes in advance and
pass undef as an argument.
Signed-off-by: Michal Nazarewicz
---
perl/Git.
From: Michal Nazarewicz
File handle goes as the first argument when calling print on it.
Signed-off-by: Michal Nazarewicz
---
perl/Git.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index bbb753a..11f310a 100644
--- a/perl/Git.pm
+++ b/perl/Git
From: Michal Nazarewicz
Add a credential() function which is an interface to the git
credential command. The code is heavily based on credential_*
functions in .
Signed-off-by: Michal Nazarewicz
---
perl/Git.pm | 110 +++-
1 file changed
From: Michal Nazarewicz
The documentation of command_close_bidi_pipe() claims that it can
be called as a method, but it does not check whether the first
argument is $self or not assuming the latter. Using _maybe_self()
fixes this.
Signed-off-by: Michal Nazarewicz
---
perl/Git.pm | 2 +-
1 fil
From: Michal Nazarewicz
Minor fixes as suggested in emails.
Michal Nazarewicz (5):
Git.pm: allow command_close_bidi_pipe to be called as method
Git.pm: fix example in command_close_bidi_pipe documentation
Git.pm: allow pipes to be closed prior to calling
command_close_bidi_pipe
Git.p
Jeff King venit, vidit, dixit 07.02.2013 10:55:
> On Thu, Feb 07, 2013 at 10:47:55AM +0100, Michael J Gruber wrote:
>
>>> I'd be OK if we had an exterior object_context that could be handled
>>> in the same way. But how do we tell setup_revisions that we are
>>> interested in seeing the object_con
On Thu, Feb 7, 2013 at 1:16 AM, Jeff King wrote:
> On Wed, Feb 06, 2013 at 04:12:10PM -0800, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason writes:
>>
>> > I think there's a simpler way to do this, which is that:
>> >
>> > * New clients supporting v2 of the protocol send some piece of data
>
On Thu, Feb 07, 2013 at 10:47:55AM +0100, Michael J Gruber wrote:
> > I'd be OK if we had an exterior object_context that could be handled
> > in the same way. But how do we tell setup_revisions that we are
> > interested in seeing the object_context from each parsed item, where
> > does the alloc
Jeff King venit, vidit, dixit 07.02.2013 10:26:
> On Thu, Feb 07, 2013 at 10:05:57AM +0100, Michael J Gruber wrote:
>
@@ -265,9 +260,28 @@ void add_object_array_with_mode(struct object *obj,
const char *name, struct obj
objects[nr].item = obj;
objects[nr].name = name;
>>
On Thu, Feb 07, 2013 at 10:34:26AM +0100, Michael J Gruber wrote:
> > Just as we record the path from the surrounding tree, we record the
> > mode. It's that mode which gets put into the pending object list by the
> > revision parser (see the very end of handle_revision_arg). Storing an
> > object
Am 07.02.2013 00:22 schrieb Jeff King:
> On Wed, Feb 06, 2013 at 10:58:49PM +0100, Sven Strickroth wrote:
>
>> Default values for *plink can be set using PuTTY. If a user makes
>> telnet the default in PuTTY this breaks ssh clones in git.
>>
>> Since git clones of the type user@host:path use ssh,
Jeff King venit, vidit, dixit 07.02.2013 10:11:
> On Thu, Feb 07, 2013 at 10:05:26AM +0100, Michael J Gruber wrote:
>
>>> Would it be better if object_array_entry replaced its "mode" member with
>>> an object_context?
>>
>> Do all callers/users want to deal with object_context?
>
> Wouldn't it ju
On Thu, Feb 07, 2013 at 10:05:57AM +0100, Michael J Gruber wrote:
> >> @@ -265,9 +260,28 @@ void add_object_array_with_mode(struct object *obj,
> >> const char *name, struct obj
> >>objects[nr].item = obj;
> >>objects[nr].name = name;
> >>objects[nr].mode = mode;
> >> + objects[nr].c
On Thu, Feb 07, 2013 at 10:05:26AM +0100, Michael J Gruber wrote:
> > Would it be better if object_array_entry replaced its "mode" member with
> > an object_context?
>
> Do all callers/users want to deal with object_context?
Wouldn't it just mean replacing "entry->mode" with "entry->oc.mode" at
Jeff King venit, vidit, dixit 06.02.2013 23:36:
> On Wed, Feb 06, 2013 at 04:08:53PM +0100, Michael J Gruber wrote:
>
>> -add_object_array(object, arg, &list);
>> +add_object_array_with_context(object, arg, &list,
>> xmemdupz(&oc, sizeof(struct object_conte
Jeff King venit, vidit, dixit 06.02.2013 23:06:
> On Wed, Feb 06, 2013 at 04:08:50PM +0100, Michael J Gruber wrote:
>
>> diff --git a/builtin/log.c b/builtin/log.c
>> index 8f0b2e8..f83870d 100644
>> --- a/builtin/log.c
>> +++ b/builtin/log.c
>> @@ -402,10 +402,28 @@ static void show_tagger(char *
Junio C Hamano venit, vidit, dixit 06.02.2013 17:53:
> Michael J Gruber writes:
>
>> Currently, "diff" and "cat-file" for blobs obey "--textconv" options
>> (with the former defaulting to "--textconv" and the latter to
>> "--no-textconv") whereas "show" does not obey this option, even though
>> i
On Thu, Feb 07, 2013 at 01:12:59PM +0900, Miles Bader wrote:
> John Keeping writes:
> > I generally like to get rid of the pointless warnings so that the useful
> > ones can't hide in the noise. Perhaps "CFLAGS += -Wno-string-plus-int"
> > would be better for this particular warning, but when the
83 matches
Mail list logo
