Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
- The always warn does not force update at the point of use, but
it still does not help them to notice well before they try to use
it for the first time after update;
I don't understand this sentence. They
Am 5/6/2014 2:17, schrieb Eric Wong:
Users may already store sensitive data such as imap.pass in
..git/config; making the file world-readable when git config
is called to edit means their password would be compromised
on a shared system.
[v2: updated for section renames, as noted by Junio]
scenario:
- edit some tracked files; do not add them to the index
- git config rebase.autostash true
- git rebase -i HEAD~3 (an autostash will be created)
- delete the entire buffer and save/exit the editor - this will abort the
rebase
poof, the autostash is gone (it is not reapplied) --
On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 5/6/2014 2:17, schrieb Eric Wong:
Users may already store sensitive data such as imap.pass in
..git/config; making the file world-readable when git config
is called to edit means their password would be compromised
On Sat, May 17, 2014 at 9:01 AM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Tue, May 13, 2014 at 09:39:59AM +0200, Ákos, Tajti wrote:
Dear List,
we implemented our own git smart http server to be able to check permissions
and other thing before pushes. It works fine, however, the
Hi all!
The Git Bash completion script does not complete the `--abort` option
for the `merge ` command.
It correctly completes the other flags.
It correctly completes the `--abort` flag for `rebase` and others.
`git merge --abort` is considered another form of the merge command
instead of a
[ Cc-ing Ramkumar ]
Karen Etheridge et...@cpan.org writes:
scenario:
- edit some tracked files; do not add them to the index
- git config rebase.autostash true
- git rebase -i HEAD~3 (an autostash will be created)
- delete the entire buffer and save/exit the editor - this will abort the
On Mon, 2014-05-19 at 18:12 +1000, Bryan Turner wrote:
On Sat, May 17, 2014 at 9:01 AM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Tue, May 13, 2014 at 09:39:59AM +0200, Ákos, Tajti wrote:
Dear List,
we implemented our own git smart http server to be able to check
On 05/18/2014 08:29 PM, Christian Couder wrote:
The usage string for this option is:
git replace [-f] --graft commit [parent...]
First we create a new commit that is the same as commit
except that its parents are [parents...]
Then we create a replace ref that replace commit with
the
On Mon, May 19, 2014 at 9:44 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 5/6/2014 2:17, schrieb Eric Wong:
Users may already store sensitive data such as imap.pass in
..git/config; making the file world-readable
On Sat, May 17, 2014 at 11:31 PM, Pasha Bolokhov
pasha.bolok...@gmail.com wrote:
Now if you guys don't see anything against this, I would shoot out a
patch?
If you have written the patch already, I see no harm in sending it
here. I'm concerned about the perfomance impact on this code,
On Fri, May 16, 2014 at 2:42 AM, David Turner dtur...@twopensource.com wrote:
I assume you won't change your mind about this. Which is fine to me. I
will still try out my approach with your libwatchman though. Just
curious about its performance and complexity, compared to your
approach.
I am
On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This tool finds people that might be interested in a patch, by going
back through the history for each single hunk modified, and finding
people that reviewed, acknowledged, signed, or authored the code the
On Sun, May 18, 2014 at 01:22:02PM -0700, Jeremiah Mahler wrote:
@@ -742,6 +743,8 @@ static int git_format_config(const char *var, const char
*value, void *cb)
}
if (!strcmp(var, format.signature))
return git_config_string(signature, var, value);
+ if
On Mon, May 19, 2014 at 11:42:07AM +0200, Michael Haggerty wrote:
On 05/18/2014 08:29 PM, Christian Couder wrote:
The usage string for this option is:
git replace [-f] --graft commit [parent...]
First we create a new commit that is the same as commit
except that its parents are
Hi,
Today I've issue a problem with git.
I've start a little project on github ( https://github.com/Djabx/mgd ).
And I used https://stackedit.io/ for editing my README.md file.
When I publish it on my repo (stackedit), I've set the destination
file path to ./README.md.
The problem is, that Git
I have run the following command:
log --graph --abbrev-commit --decorate --date=relative
--format=format:'%C(bold blue)%h%C(reset)%x09%C(bold
green)(%ar)%C(reset)%C(bold yellow)%d%C(reset) %C(dim
white)%an%C(reset) - %C(white)%s%C(reset)'
After running this, I am seeing tag labels in the log
From: Cezary Zawadka czawa...@gmail.com
Date: Tue, 13 Jul 2010 16:17:43 +0200
[efl: moved MinGW-specific part to compat/]
[jes: fixed compilation on non-Windows]
Eric Sunshine fixed mingw_offset_1st_component() to return consistently foo
for UNC //machine/share/foo, cf
On Mon, May 19, 2014 at 03:05:42PM +0200, Alexandre Badez wrote:
The '.' directory is not the same as the root directory; you can see
that the /README.md and /./README.md are different.
Right. Inside git trees, . as an entry name does not have any special
meaning. However, because it does have
On Mon, May 19, 2014 at 08:17:07AM -0500, Robert Dailey wrote:
I have run the following command:
log --graph --abbrev-commit --decorate --date=relative
--format=format:'%C(bold blue)%h%C(reset)%x09%C(bold
green)(%ar)%C(reset)%C(bold yellow)%d%C(reset) %C(dim
white)%an%C(reset) -
`git push` writes to stderr instead of stdout
Steps to reproduce:
mkdir foo
cd foo
git init
echo foo fo
git add -A
git commit -am foo
git push . HEAD:refs/heads/newbranch 2out
Expected: `out` file is empty
Actual: `out` file contents:
To .
* [new branch] HEAD - newbranch
On Mon, May 19, 2014 at 06:12:10PM +1000, Bryan Turner wrote:
For starters, to return an error message, your status must be 200 OK.
You can't return any other status code or Git will interpret your
error as some form of _HTTP_ error rather than a _git_ error.
As of git v1.8.3, git will show
This patch series differs from the previous (v2) version in the following:
t4205 refactored: hardcoded SHA-1 digests replaced with variabled
Tested encoding `iso8859-1` replaced with variable (and uppercased to be in line
in other tests)
Usage of `format` + `echo` replaced with `tformat`
brian
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
That was introduced in a742f2a (t4205 (log-pretty-formats): don't
hardcode SHA-1 in expected outputs, 2013-06-26) but unfortunately was
not followed in 5e1361c (log: properly handle decorations with
The tested encoding is always available in a variable. Use it instead of
hardcoding. Also, to be in line with other tests use ISO8859-1
(uppercase) rather then iso8895-1.
Signed-off-by: Alexey Shumkin alex.crez...@gmail.com
---
t/t4041-diff-submodule-option.sh | 7 +--
Pretty format string %(N,[ml]trunc)%s truncates subject to a given
length with an appropriate padding. This works for non-ASCII texts when
i18n.logOutputEncoding is UTF-8 only (independently of a printed commit
message encoding) but does not work when i18n.logOutputEncoding is NOT
UTF-8.
There
Pretty format string %(N,[ml]trunc)%s truncates subject to a given
length with an appropriate padding. This works for non-ASCII texts when
i18n.logOutputEncoding is UTF-8 only (independently of a printed commit
message encoding) but does not work when i18n.logOutputEncoding is NOT
UTF-8.
In
Hi,
Is there any difference between the below 2 commands ? I didn't see anything.
git rm --cached -- file1 .. fileN
git checkout -- file1 .. fileN
--
===
Regards,
Arup Rakshit
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Mon, May 19, 2014 at 07:03:58PM +0400, Marat Radchenko wrote:
`git push` writes to stderr instead of stdout
That's by design.
Which one is correct is largely a matter of philosophy / mental model.
This case has been discussed before:
On 5/19/2014 2:44 AM, Erik Faye-Lund wrote:
On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt j.s...@viscovery.net
wrote:
I'm not proficient enough to add any ACL fiddling to fchmod that
would be required by the above change, whose purpose is to be
strict about permissions. Nor am I interested
On Mon, May 19, 2014 at 09:12:47PM +0630, Arup Rakshit wrote:
Is there any difference between the below 2 commands ? I didn't see anything.
git rm --cached -- file1 .. fileN
This one removes the index entries for those files.
git checkout -- file1 .. fileN
This one checks out the
On Monday, May 19, 2014 09:12:47 PM you wrote:
Hi,
Is there any difference between the below 2 commands ? I didn't see
anything.
git rm --cached -- file1 .. fileN
git checkout -- file1 .. fileN
Please Ignore the previous.
I apologize to rewriting and increase the load of this mailing
Michael S. Tsirkin m...@redhat.com writes:
Well RHEL6 apparently comes with git 1.7.1, there are
probably others.
The problem isn't theorectical actually,
Thanks. Let's do the fix for 2.0 then.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Mon, May 19, 2014 at 11:49:09AM -0400, Jeff King wrote:
On Mon, May 19, 2014 at 07:03:58PM +0400, Marat Radchenko wrote:
`git push` writes to stderr instead of stdout
That's by design.
Which one is correct is largely a matter of philosophy / mental model.
This case has been
On Mon, May 19, 2014 at 09:27:47PM +0630, Arup Rakshit wrote:
Is there any difference between the below 2 commands ? I didn't see
anything.
git rm --cached -- file1 .. fileN
git checkout -- file1 .. fileN
Please Ignore the previous.
Too late. :)
I apologize to rewriting and
Jeremiah Mahler jmmah...@gmail.com writes:
On Sat, May 17, 2014 at 06:00:14AM -0400, Jeff King wrote:
If you wanted to know whether it was set, I guess you'd have to compare
it to the default, like:
if (signature_file) {
if (signature signature != git_version_string)
On Fri, May 16, 2014 at 3:52 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Ronnie Sahlberg wrote:
Change store_updated_refs to use a single ref transaction for all refs that
are updated during the fetch. This makes the fetch more atomic when update
failures occur.
Fun.
[...]
---
On Fri, May 16, 2014 at 3:54 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Ronnie Sahlberg wrote:
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
[...]
@@ -384,15 +384,16 @@ static int s_update_ref(const char *action,
snprintf(msg, sizeof(msg), %s: %s, rla, action);
errno = 0;
-
Anders Kaseorg ande...@mit.edu writes:
Yes; when I noticed this failure, I asked Jonathan to add source-highlight
as a build dependency in Debian (https://bugs.debian.org/745591). But
then Ubuntu forked the packaging to revert this change
(https://bugs.launchpad.net/bugs/1316810), because
On Monday, May 19, 2014 12:01:07 PM you wrote:
On Mon, May 19, 2014 at 09:12:47PM +0630, Arup Rakshit wrote:
Is there any difference between the below 2 commands ? I didn't see
anything.
Does that help?
For me who is in Git just 6-7 days, It is huge. On your way, I was walking to
On Sat, May 17, 2014 at 6:09 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 05/16/2014 07:37 PM, Ronnie Sahlberg wrote:
Change tag.c to use ref transactions for all ref updates.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/tag.c | 14 --
1 file changed, 8
Jens Lehmann jens.lehm...@web.de writes:
Am 17.05.2014 14:23, schrieb Pat Thoyts:
The analysis about the major version number being significant is
correct. ...
package vsatisfies $::_git_version 1.7.0-
will suffice.
Junio, please replace my old version with this.
Thanks, both.
On Sat, May 17, 2014 at 6:33 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 05/16/2014 07:37 PM, Ronnie Sahlberg wrote:
Change create_branch to use a ref transaction when creating the new branch.
ref_transaction_create will check that the ref does not already exist and
fail
otherwise
Jeff King p...@peff.net writes:
It might make sense to just teach parse_commit_header to be a little
more thorough; it has to read past those lines anyway to find the author
and committer lines, so it would not be much more expensive to note
them. And then of course the code needs to be
On Mon, May 19, 2014 at 10:25:10AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
It might make sense to just teach parse_commit_header to be a little
more thorough; it has to read past those lines anyway to find the author
and committer lines, so it would not be much more
I have moved the patch to add err to ref_transaction_begin to the
current patch series.
Please see
https://github.com/rsahlberg/git/tree/ref-transactions
On Mon, May 19, 2014 at 10:16 AM, Ronnie Sahlberg sahlb...@google.com wrote:
On Sat, May 17, 2014 at 6:09 AM, Michael Haggerty
I have moved the patch to add an err argument to this branch and
update all patches that adds
calls to ref_Transaction_begin to the new signature.
Please see
https://github.com/rsahlberg/git/tree/ref-transactions
Thanks!
On Sat, May 17, 2014 at 6:14 AM, Michael Haggerty mhag...@alum.mit.edu
Jeff King p...@peff.net writes:
On Mon, May 19, 2014 at 10:25:10AM -0700, Junio C Hamano wrote:
The headers up to committer are cast in stone in their ordering, and
I do not immediately see how loosening it would be beneficial.
Unless you are trying to give users a new way to record
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
2. add warning that is given every time the scripts are run and
give the same instruction as in README.
3. (optional) cripple the script to make them always fail after
showing the same warning as
On Sat, May 17, 2014 at 8:35 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 05/16/2014 07:37 PM, Ronnie Sahlberg wrote:
Wrap all the ref updates inside a transaction to make the update atomic.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
builtin/receive-pack.c | 20
Am Montag, den 19.05.2014, 11:59 +0200 schrieb Erik Faye-Lund:
On Mon, May 19, 2014 at 9:44 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 5/6/2014 2:17, schrieb Eric Wong:
Users may already store sensitive data
On Mon, May 19, 2014 at 9:17 PM, Thomas Braun
thomas.br...@virtuell-zuhause.de wrote:
Am Montag, den 19.05.2014, 11:59 +0200 schrieb Erik Faye-Lund:
On Mon, May 19, 2014 at 9:44 AM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, May 19, 2014 at 9:13 AM, Johannes Sixt j.s...@viscovery.net
Since commit 0c499ea60f the send-pack builtin uses the side-band-64k
capability if advertised by the server. Unfortunately this breaks
pushing over the dump git protocol with a windows git client.
The detailed reasons for this breakage are (by courtesy of Jeff
Preshing, quoted from
Hi,
Thomas Braun wrote:
pushing over the dump git protocol with a windows git client.
I've never heard of the dump git protocol. Do you mean the git
protocol that's used with git:// URLs?
[...]
Alternative approaches considered but deemed too invasive:
- Rewrite read/write wrappers in
I tried to fump the whole history of qemu with format-patch.
It crashes both with v2.0.0-rc2-21-g6087111
and with git 1.8.3.1:
~/opt/libexec/git-core/git-format-patch --follow -o patches/all
e63c3dc74bfb90e4522d075d0d5a7600c5145745..
Backtrace:
Program received signal SIGSEGV, Segmentation
On Mon, May 19, 2014 at 9:33 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Thomas Braun wrote:
pushing over the dump git protocol with a windows git client.
I've never heard of the dump git protocol. Do you mean the git
protocol that's used with git:// URLs?
[...]
Alternative
On Mon, May 19, 2014 at 10:00 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Mon, May 19, 2014 at 9:33 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Thomas Braun wrote:
pushing over the dump git protocol with a windows git client.
I've never heard of the dump git protocol. Do you
Christian Couder chrisc...@tuxfamily.org writes:
This patch series comes from what Peff sent in the following thread:
http://thread.gmane.org/gmane.comp.version-control.git/243361/focus=243528
The only changes compared to v2 are in the test (8/10) and documentation
patches (10/10). Thanks
Felipe Contreras felipe.contre...@gmail.com writes:
...
Which will generate the integration instructions for you:
% git reintegrate --cat
base master
merge jl/submodule-mv
Moving a regular file in a repository with a .gitmodules file was
producing a warning 'Could not find
Am 19.05.2014 21:33, schrieb Jonathan Nieder:
Hi,
Thomas Braun wrote:
pushing over the dump git protocol with a windows git client.
I've never heard of the dump git protocol. Do you mean the git
protocol that's used with git:// URLs?
You are right I mean the protocol involving git://
On Mon, May 19, 2014 at 11:15 PM, Thomas Braun
thomas.br...@byte-physics.de wrote:
Am 19.05.2014 21:33, schrieb Jonathan Nieder:
Hi,
Thomas Braun wrote:
pushing over the dump git protocol with a windows git client.
I've never heard of the dump git protocol. Do you mean the git
protocol
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
After looking at the reverse-depends list of packages, my faith is
strengthened in that the Git ecosystem is truly maturing and useful
third-party plug-ins will be picked up by distro packagers.
Where is git-imerge
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
- The always warn does not force update at the point of use, but
it still does not help them to notice well before they try to use
it for the first time after update;
I don't
Michael S. Tsirkin m...@redhat.com writes:
test ack! handling
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Will queue with this squashed in.
4/4 seems to have some style issues as well, but I didn't look very
closely.
Thanks.
t/t3415-rebase-autosquash.sh | 12 ++--
1 file
Ævar Arnfjörð Bjarmason wrote:
On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This tool finds people that might be interested in a patch, by going
back through the history for each single hunk modified, and finding
people that reviewed, acknowledged,
When a user invokes
$ git rebase -i @~3
with dirty files and rebase.autostash turned on, and exits the $EDITOR
with an empty buffer, the autostash fails to apply. Although the primary
focus of rr/rebase-autostash was to get the git-rebase--backend.sh
scripts to return control to git-rebase.sh,
Felipe Contreras felipe.contre...@gmail.com writes:
We could add these two to the warning, then, to discourage people
who see please visit this URL and say Yuck, I have no time for
that without actually visiting.
We could. Personally I don't see the point of making the warning any
more
On Mon, May 19, 2014 at 02:34:26PM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
test ack! handling
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Will queue with this squashed in.
Thanks! And sorry about the style issues.
4/4 seems to have some style
Not all shells subject the prompt string to parameter expansion. Test
whether the shell will expand the value of PS1, and use the result to
control whether raw ref names are included directly in PS1.
This fixes a regression introduced in commit 8976500 (git-prompt.sh:
don't put unsanitized
On Fri, May 16, 2014 at 2:24 PM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
When performing a reflog transaction update, only write to the reflog iff
msg is non-NULL. This can then be combined with REFLOG_TRUNCATE to perform
an update that only
On Fri, May 16, 2014 at 3:01 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Fri, May 16, 2014 at 5:35 PM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
Allow to make multiple reflog updates to the same ref during a transaction.
This means we only
On Fri, May 16, 2014 at 2:35 PM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
Allow to make multiple reflog updates to the same ref during a transaction.
This means we only need to lock the reflog once, during the first update that
touches the reflog,
On Fri, May 16, 2014 at 2:15 PM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
Rename the transaction functions. Remove the leading ref_ from the names
and append _sha1 to the names for functions that create/delete/update sha1
refs.
...
-
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
We could. Personally I don't see the point of making the warning any
more annoying
If we were giving the users a choice of no thanks, I'll keep using
the obsolete one, then trying to be a low key
Ronnie Sahlberg sahlb...@google.com writes:
I am not sure if we need transactions for other types of data, such as
sha1 objects, but if it turns out we do in the future we can rename
these functions again.
I was wrong (and I think you read it in the later patch review).
If we need
On Fri, May 16, 2014 at 2:20 PM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
Add a flag that allows us to truncate the reflog before we write the update.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
---
Until we read the callers it is hard to
On Mon, 19 May 2014, Junio C Hamano wrote:
If Ubuntu does not want to use highlight, it can apply a change like the
patch in question as part of their fork to make the end result
consistent and they are failing to do so.
Sure, Ubuntu can apply that patch, but the larger problem remains: if
Jason St. John jstj...@purdue.edu writes:
Signed-off-by: Jason St. John jstj...@purdue.edu
---
Please accept Thanks for all the hunks I won't comment below; they
looked correct to me.
@@ -53,7 +53,7 @@ Updates since v1.9 series
UI, Workflows Features
* The multi-mail post-receive
On Mon, May 19, 2014 at 07:28:17PM +0400, Alexey Shumkin wrote:
The tested encoding is always available in a variable. Use it instead of
hardcoding. Also, to be in line with other tests use ISO8859-1
(uppercase) rather then iso8895-1.
You wrote iso8895 when I think you meant iso8859.
--
Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
We could. Personally I don't see the point of making the warning any
more annoying
If we were giving the users a choice of no thanks, I'll keep using
the obsolete
On 2014-05-19 19:46, Junio C Hamano wrote:
Jason St. John jstj...@purdue.edu writes:
@@ -53,7 +53,7 @@ Updates since v1.9 series
UI, Workflows Features
* The multi-mail post-receive hook (in contrib/) has been updated
- to a more recent version from the upstream.
+ to a more
Richard Hansen rhan...@bbn.com writes:
On 2014-05-19 19:46, Junio C Hamano wrote:
Jason St. John jstj...@purdue.edu writes:
@@ -53,7 +53,7 @@ Updates since v1.9 series
UI, Workflows Features
* The multi-mail post-receive hook (in contrib/) has been updated
- to a more recent
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
We could. Personally I don't see the point of making the warning any
more annoying
If we were giving the users
On Mon, May 19, 2014 at 09:54:33AM -0700, Junio C Hamano wrote:
Jeremiah Mahler jmmah...@gmail.com writes:
On Sat, May 17, 2014 at 06:00:14AM -0400, Jeff King wrote:
Avoiding that is easy with an indirection, no? Something like this
at the top:
static const char
84 matches
Mail list logo
