On Wed, Jan 23, 2013 at 7:44 AM, Junio C Hamano wrote:
> But I do not think the loop structure of this function is right. If
> $D has ".git" in it, should it even try to feed other subdirectories
> of $D (say "$D/a") to itself in recursion to see if $D/a/.git exists?
Yes, this is needed to meet
Jeff King wrote:
> So I've re-rolled the original version
Lovely. :)
Reviewed-by: Jonathan Nieder
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jeff King writes:
> This doesn't save any lines, but does keep us from doing
> error-prone pointer arithmetic with constants.
Yeah, this and 7/8 shows that the true value of the new parse
function is not line number reduction but clarity of the calling
code. There is really no point making ever
On Mon, Jan 21, 2013 at 10:30:29PM -0800, Junio C Hamano wrote:
> When we push to update an existing ref, if:
>
> * we do not have the object at the tip of the remote; or
> * the object at the tip of the remote is not a commit; or
> * the object we are pushing is not a commit,
>
> there is no
Lars Hjemli writes:
> +static struct option builtin_all_options[] = {
> + OPT_BOOLEAN('c', "clean", &only_clean, N_("only show clean
> repositories")),
> + OPT_BOOLEAN('d', "dirty", &only_dirty, N_("only show dirty
> repositories")),
> + OPT_END(),
> +};
If you were to go in the OP
David Aguilar writes:
>> +static int walk(struct strbuf *path, int argc, const char **argv)
>> +{
>> + DIR *dir;
>> + struct dirent *ent;
>> + size_t len;
>> +
>> + dir = opendir(path->buf);
>> + if (!dir)
>> + return errno;
>> + strbuf_addstr(pat
On Mon, Jan 21, 2013 at 10:30:28PM -0800, Junio C Hamano wrote:
> The "nonfastforward" and "update" fields are only used while
> deciding what value to assign to the "status" locally in a single
> function. Remove them from the "struct ref".
>
> The "requires_force" field is not used to decide i
This doesn't save any lines, but does keep us from doing
error-prone pointer arithmetic with constants.
Signed-off-by: Jeff King
---
builtin/reflog.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/builtin/reflog.c b/builtin/reflog.c
index b3c9e27..1fedf66 10064
The resulting code ends up about the same length, but it is
a little more self-explanatory. It now explicitly documents
and checks the pre-condition that the incoming var starts
with "man.", and drops the magic offset "4".
Signed-off-by: Jeff King
---
builtin/help.c | 14 +++---
1 file c
We keep a strbuf for the name of the submodule, even though
we only ever add one string to it. Let's just use xmemdupz
instead, which is slightly more efficient and makes it
easier to follow what is going on.
Unfortunately, we still end up having to deal with some
memory ownership issues in some c
This makes the code a lot simpler to read by dropping a
whole bunch of constant offsets.
As a bonus, it means we also feed the whole config variable
name to our error functions:
[before]
$ git -c submodule.foo.fetchrecursesubmodules=bogus checkout
fatal: bad foo.fetchrecursesubmodules argum
When we parse userdiff config, we generally assume that
diff.name.key
will affect the "key" value of the "name" driver. However,
without confirming that the key is a valid userdiff key, we
may accidentally conflict with the ancient "diff.color.*"
namespace. The current code is careful not to ev
These callers can drop some inline pointer arithmetic and
magic offset constants, making them more readable and less
error-prone (those constants had to match the lengths of
strings, but there is no automatic verification of that
fact).
The "ep" pointer (presumably for "end pointer"), which
points
This is fewer lines of code, but more importantly, fixes a
bogus pointer offset. We are looking for "tar." in the
section, but later assume that the dot we found is at offset
9, not 3. This is a holdover from an earlier iteration of
767cf45 which called the section "tarfilter".
As a result, we cou
The config callback functions get keys of the general form:
section.subsection.key
(where the subsection may be contain arbitrary data, or may
be missing). For matching keys without subsections, it is
simple enough to call "strcmp". Matching keys with
subsections is a little more complicated, a
On Fri, Jan 18, 2013 at 12:53:32PM -0800, Junio C Hamano wrote:
> >> ... did you have any comment on
> >> the "struct config_key" alternative I sent as a follow-up?
> >
> > I did read it but I cannot say I did so very carefully. My gut
> > reaction was that the "take the variable name and section
David Aguilar writes:
> On Mon, Jan 21, 2013 at 11:19 AM, Thomas Ackermann wrote:
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>> index b87f744..5a831ad2 100644
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> push.default::
>> - Defines the ac
On Mon, Jan 21, 2013 at 11:19 AM, Thomas Ackermann wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index b87f744..5a831ad2 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> push.default::
> - Defines the action git push should take if no
Leftover in paths touched by [5/6].
Documentation/gitcvs-migration.txt | 2 +-
Documentation/technical/api-builtin.txt | 2 +-
Documentation/technical/api-credentials.txt | 4 ++--
Documentation/technical/api-remote.txt | 2 +-
Documentation/urls.txt | 2 +-
Eric Wong writes:
> `git rev-parse --show-cdup` outputs nothing if GIT_DIR is set,
> so I unset GIT_DIR temporarily.
>
> I'm not sure why --show-cdup behaves like this, though..
Setting GIT_DIR is to say "That is the directory that has the
repository objects and refs; I am letting you know the l
Documentation/gitcore-tutorial.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitcore-tutorial.txt
b/Documentation/gitcore-tutorial.txt
index 5d957c2..59c1c17 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -10
Junio C Hamano writes:
> As before, I'll locally create a fixup commit based on the above.
>
> After I am done with these patches, somebody (not Thomas or I, as
> our eyes are too used to staring at git and Git to notice mistakes)
> has to run "git grep -C3 -e '\' Documentation/" and eyeball
> th
In Documentation/git-rev-parse.txt, there is this bit:
--resolve-git-dir ::
Check if is a valid git-dir or a git-file pointing to
a valid git-dir. If is a valid git-dir the resolved path to
git-dir will be printed.
I think the author invented the word "git-dir" to mean
Barry Wardell wrote:
> These patches fix a bug which prevented git-svn from working with repositories
> which use gitdir links.
>
> Changes since v2:
> - Rebased onto latest master.
> - Added test case which verifies that the problem has been fixed.
> - Fixed problems with git svn (init|clone|
Junio C Hamano writes:
> This is the summary of the review comments in a patch form.
>
And then there still are the ones in the file that was touched by
Thomas's 2/6 that need fixing.
Documentation/git-apply.txt | 2 +-
Documentation/git-archimport.txt | 2 +-
Documentation/git-cv
On Wed, Jan 23, 2013 at 5:51 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> We obviously do not want to set FNM_PATHNAME when we are not
>> substituting fnmatch() with wildmatch(), but I wonder if it may make
>> sense to unconditionally use WM_PATHNAME semantics when we build the
>> syst
Thomas Ackermann writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index b87f744..5a831ad2 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1,14 +1,14 @@
> CONFIGURATION FILE
> --
>
> -The git configuration file contains
On Tue, Jan 22, 2013 at 1:10 PM, Lars Hjemli wrote:
> When working with multiple, unrelated (or loosly related) git repos,
> there is often a need to locate all repos with uncommitted work and
> perform some action on them (say, commit and push). Before this patch,
> such tasks would require manua
This is the summary of the review comments in a patch form.
Subject: [PATCH] fixup! Change 'git' to 'Git' whenever the whole system is
referred to #1
---
Documentation/Makefile | 4 ++--
Documentation/git-clean.txt | 2 +-
Documentation/git-clone.txt | 2 +-
Docume
Lars Hjemli writes:
> In principle I agree with your reasoning on this, but in practice I
> fail to see what other kind of things `git all` could naturally refer
> to.
For example, the designers of 'for-each-ref' could have called it
"git all", as it is to iterate over all refs.
--
To unsubscrib
John Keeping writes:
> On Tue, Jan 22, 2013 at 02:44:48PM -0800, Junio C Hamano wrote:
>> * jc/cvsimport-upgrade (2013-01-14) 8 commits
>> - t9600: adjust for new cvsimport
>> - t9600: further prepare for sharing
>> - cvsimport-3: add a sample test
>> - cvsimport: make tests reusable for cvsi
Thomas Ackermann writes:
> Signed-off-by: Thomas Ackermann
> ---
> diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
> index 9f42c0d..14bdbbb 100644
> --- a/Documentation/git-clean.txt
> +++ b/Documentation/git-clean.txt
> @@ -33,7 +33,7 @@ OPTIONS
>
> -f::
> --force::
On Tue, Jan 22, 2013 at 02:44:48PM -0800, Junio C Hamano wrote:
> * jc/cvsimport-upgrade (2013-01-14) 8 commits
> - t9600: adjust for new cvsimport
> - t9600: further prepare for sharing
> - cvsimport-3: add a sample test
> - cvsimport: make tests reusable for cvsimport-3
> - cvsimport: start
On Tue, Jan 22, 2013 at 11:01 PM, Junio C Hamano wrote:
> Lars Hjemli writes:
>
>> +static struct option builtin_all_options[] = {
>> + OPT_BOOLEAN('c', "clean", &only_clean, N_("only show clean
>> repositories")),
>> + OPT_BOOLEAN('d', "dirty", &only_dirty, N_("only show dirty
>> repos
Junio C Hamano writes:
> We obviously do not want to set FNM_PATHNAME when we are not
> substituting fnmatch() with wildmatch(), but I wonder if it may make
> sense to unconditionally use WM_PATHNAME semantics when we build the
> system with USE_WILDMATCH and calling wildmatch() in this codepath.
On 01/22/2013 05:14 PM, Thomas Rast wrote:
Eric Chamberland writes:
So, hum, do we have some sort of conclusion?
Shall it be a fix for git to get around that lustre "behavior"?
If something can be done in git it would be great: it is a *lot*
easier to change git than the lustre filesystem so
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 sometime in the middle of next month.
You can find the changes
Torsten Bögershausen writes:
>> So it finds whatever is before the first "-", which would be the test
>> number in "t-basic.sh" or similar, and then looks for duplicates.
>
> would it help to filter for numbered tests before sorting like this:
>
> sed 's/-.*//' | grep "[0-9][0-9][0-9][0-9]"|
Eric Chamberland writes:
> So, hum, do we have some sort of conclusion?
>
> Shall it be a fix for git to get around that lustre "behavior"?
>
> If something can be done in git it would be great: it is a *lot*
> easier to change git than the lustre filesystem software for a cluster
> in running in
Eric Chamberland writes:
> So, hum, do we have some sort of conclusion?
>
> Shall it be a fix for git to get around that lustre "behavior"?
>
> If something can be done in git it would be great: it is a *lot*
> easier to change git than the lustre filesystem software for a cluster
> in running in
Lars Hjemli writes:
> diff --git a/builtin/all.c b/builtin/all.c
> new file mode 100644
> index 000..ee9270d
> --- /dev/null
> +++ b/builtin/all.c
> @@ -0,0 +1,105 @@
> +/*
> + * "git all" builtin command.
> + *
> + * Copyright (c) 2013 Lars Hjemli
> + */
> +#include "cache.h"
> +#include "c
Nguyễn Thái Ngọc Duy writes:
> "**" is adjusted to only be effective when surrounded by slashes, in
> 40bbee0 (wildmatch: adjust "**" behavior - 2012-10-15). Except that
> the commit did it wrong:
>
> 1. when it checks for "the preceding slash unless ** is at the
>beginning", it compares to
So, hum, do we have some sort of conclusion?
Shall it be a fix for git to get around that lustre "behavior"?
If something can be done in git it would be great: it is a *lot* easier
to change git than the lustre filesystem software for a cluster in
running in production mode... (words from clus
When working with multiple, unrelated (or loosly related) git repos,
there is often a need to locate all repos with uncommitted work and
perform some action on them (say, commit and push). Before this patch,
such tasks would require manually visiting all repositories, running
`git status` within ea
On 22.01.13 20:41, Jeff King wrote:
> On Tue, Jan 22, 2013 at 12:49:31AM -0500, John Szakmeister wrote:
>
>> I tried running make in contrib/remote-helpers and it died with:
>>
>> :: make
>> make -e -C ../../t test
>> rm -f -r test-results
>> duplicate test numbers: /Users/jszakmei
- Ursprungligt meddelande -
> Also, even though we settled on "default/minimal", we may regret in
> the future if old implementations died on an unrecognized value, as
> that will forbid users from using an old Git and a new Git on the
> same repository at the same time, so I'd suggest r
On Mon, Jan 21, 2013 at 05:45:05PM -0800, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > On Tue, Jan 22, 2013 at 6:15 AM, Jeff King wrote:
> >> Can you elaborate on when this code is triggered?
> >>
> >> In the general case, shouldn't we already know the sha1 of what's on
> >> disk in the ind
On Tue, Jan 22, 2013 at 12:49:31AM -0500, John Szakmeister wrote:
> I tried running make in contrib/remote-helpers and it died with:
>
> :: make
> make -e -C ../../t test
> rm -f -r test-results
> duplicate test numbers: /Users/jszakmeister/sources/git
> make[1]: *** [test-lin
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Torsten Bögershausen wrote:
> On 20.01.13 12:06, Jonathan Nieder wrote:
>> Torsten Bögershausen wrote:
>>
>>> I wonder, if if we can go one step further:
>>>
>>> Replace
>>> #ifdef WIN32 /* Both MinGW and MSVC */
>> [...]
>>> with
>>> #if defined(_MSC_VER)
>>
>> I thought Git for Windows was built
Commit fa2364ec ("Which merge_file() function do you mean?", 06-12-2012)
renamed the files merge-file.[ch] to merge-blobs.[ch], but forgot to
rename the header file in the definition of the LIB_H macro.
Signed-off-by: Ramsay Jones
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
Jonathan Nieder wrote:
> Ramsay Jones wrote:
>
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -85,12 +85,6 @@
>> #define _NETBSD_SOURCE 1
>> #define _SGI_SOURCE 1
>>
>> -#ifdef WIN32 /* Both MinGW and MSVC */
>> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h
>
> I left this as-is in my "fixup" commit, as the html and manpage
> backends seem to typeset the section titles differently. I however
> have to wonder what the result will look like if we replaced it with
>
> Typical use of Git credential
>
> Can you try and see how well it works?
>
Paul Mackerras writes:
> On Tue, Jan 01, 2013 at 06:54:23PM +0100, Stefan Haller wrote:
>> Jason Holden wrote:
>>
>> > I was testing some patches against the latest gitk, and noticed that when I
>> > click the mouse on the lines that connect the commits in the history graph,
>> > I get an error
Robin Rosenberg writes:
> Specifically the fields uid, gid, ctime, ino and dev are set to zero
> by JGit. Other implementations, eg. Git in cygwin are allegedly also
> somewhat incompatible with Git For Windows and on *nix platforms
> the resolution of the timestamps may differ.
>
> Any stat chec
+core.checkstat::
+ Determines which stat fields to match between the index
+ and work tree. The user can set this to 'default' or
+ 'minimal'. Default (or explicitly 'default'), is to check
+ all fields, including the sub-second part of mtime and ctime.
+
Setting 'minimal'
Andrey Borzenkov writes:
> I renamed branches and noticed that branch name was not changed in
> remote push config. I.e. after
>
> bor@opensuse:~/src/bootinfoscript> git branch -m github master
>
> I still have
>
> [remote "github"]
> push = github:master
> url = git://github.com/
Thomas Ackermann writes:
>> * Documentation/git-credential.txt:
>> TYPICAL USE OF GIT CREDENTIAL
>>
> This is to be debated because here all caps is used as "poor man's bold face"
> and it would look odd if we write 'TYPICAL USE OF Git CREDENTIAL'?
I left this as-is in my "fixup" commit, as th
Jean-Noël Avila writes:
> Le 22/01/2013 05:31, Junio C Hamano a écrit :
>> Jeff King writes:
>>
>>> I really hate to suggest this, but should it be more like:
>>>
>>> if test -z "$FAKE_COMMAND_LIST"; then __git_cmdlist() { git help -a
>>> | egrep '^ [a-zA-Z0-9]' } else __git_cmdlist() { printf
gree...@obbligato.org writes:
> Junio, is there a policy for backward-compatability in contrib? I hope
> that since that directory is for stuff not yet in mainline, there is
> some room to massage the user interface.
I do not think there is anything more than "we wish there were fewer
such end-u
Hello,
We recently changed from using CVS to GIT, previous company I worked
we used clearcase.
We do feature development / bug fixing (complex) on branches, trivial
changes commit direct on Develop branch.
What I am missing in all the gui tools is the relation on what
specific branch did
I renamed branches and noticed that branch name was not changed in
remote push config. I.e. after
bor@opensuse:~/src/bootinfoscript> git branch -m github master
I still have
[remote "github"]
push = github:master
url = git://github.com/arvidjaar/bootinfoscript.git
pushurl
On Tue, Jan 22, 2013 at 1:49 AM, Jonathan Nieder wrote:
> Jonathan Nieder wrote:
>
>> Here is the loop in master:
>>
>> int hit = 0;
>> [...]
>>
>> for (i = len - 1; i > 0; i--) {
>> if (hit && buf[i] == '\n')
>> break;
>> hit = (buf[i]
Jonathan Nieder wrote:
> line) instead of buf[i] is a whitespace character. So for example, it
> confuses the following for a well-formed RFC2822 footer:
Luckily it doesn't, since the final continuation line is not followed
by whitespace. I should have said:
"... is a white
Brandon Casey wrote:
> On Mon, Jan 21, 2013 at 11:54 PM, Jonathan Nieder wrote:
>>> - if ((buf[k] == ' ' || buf[k] == '\t') && !first)
>>> - continue;
>>
>> This is always the first line examined, so this "continue" never
>> triggers.
>
> This is just totally broke
Jonathan Nieder wrote:
> Here is the loop in master:
>
> int hit = 0;
> [...]
>
> for (i = len - 1; i > 0; i--) {
> if (hit && buf[i] == '\n')
> break;
> hit = (buf[i] == '\n');
> }
>
> I don't see any adjacency check.
Of course
Brandon Casey wrote:
> On Mon, Jan 21, 2013 at 11:54 PM, Jonathan Nieder wrote:
>> First (snipped), it seeks back two newlines from the end and then
>> forward to the next non-newline character, so (buf + i) is at the
>> start of the last line of (the interesting part of) sb.
>
> Did you catch th
>
> I think it misses "GIT - the stupid content tracker" in README, but
> probably it is OK (it is not an end-user facing documentation).
>
I only checked ./Documentation; but this should be changed also.
> I noticed that these two places still use poor-man's small caps
> after this patch.
>
Th
On Tue, Jan 22, 2013 at 12:02 AM, Jonathan Nieder wrote:
> Brandon Casey wrote:
>> --- a/t/test-lib-functions.sh
>> +++ b/t/test-lib-functions.sh
>> @@ -135,12 +135,13 @@ test_pause () {
>> fi
>> }
>>
>> -# Call test_commit with the arguments " [ []]"
>> +# Call test_commit with the argume
On Mon, Jan 21, 2013 at 11:54 PM, Jonathan Nieder wrote:
> Hi,
>
> Brandon Casey wrote:
>
>> --- a/sequencer.c
>> +++ b/sequencer.c
> [...]
>> @@ -1042,13 +1041,8 @@ static int ends_rfc2822_footer(struct strbuf *sb, int
>> ignore_footer)
>
> Git is checking if (sb->buf) ends with a "Signed-off-by
James Nylen writes:
> I just now saw these emails. I'm having a hard time thinking of any
> good use case other than:
>
> - add "fancylib" as a subtree of "myprog"
> - commit to myprog repo: "fancylib: don't crash as much"
> - split these commits back out to fancylib's main repo, and remove
>
James Nylen writes:
> Wow, I missed a bunch of emails on this. Thanks for applying and for
> writing tests!
Sorry it took so long.
> This is as intended. You wouldn't want subtree to modify commits that
> occurred in the full repository for project A. Furthermore, you
> wouldn't have a "subp
Junio C Hamano writes:
> gree...@obbligato.org writes:
>
>> Are you incorporating the other patches? Should I drop them
>> from my list?
>
> I actually was planning to accept patches to this subdirectory only
> through you, hopefully as messages that forward others' changes with
> your Acked-by:
Brandon Casey wrote:
> Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
> This is in preparation to unify the append_signoff implementations in
> log-tree.c and sequencer.c.
[...]
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1082,9 +1101,10 @@ int sequencer_pick_revision
Junio C Hamano writes:
> gree...@obbligato.org writes:
>
>> gree...@obbligato.org writes:
>>
I think this paragraph inherits existing breakage from the beginning
of time, but I do not think the above will format the second and
subsequent paragraphs correctly.
>>>
>>> Ok, I'll take
Brandon Casey wrote:
> Start treating the "(cherry picked from" line added by cherry-pick -x
> the same way that the s-o-b lines are treated. Namely, separate them
> from the main commit message body with an empty line.
Heh, you read my mind.
--
To unsubscribe from this list: send the line "unsu
Brandon Casey wrote:
> Let's detect "(cherry picked from...)" as part of the footer so that we
> will produce this:
>
>Signed-off-by: A U Thor
>(cherry picked from da39a3ee5e6b4b0d3255bfef95601890afd80709)
>Signed-off-by: C O Mmitter
>
> instead of this:
>
>Signed-off-by: A U Tho
Am 1/22/2013 8:49, schrieb Robin Rosenberg:
> Specifically the fields uid, gid, ctime, ino and dev are set to zero
> by JGit. Other implementations, eg. Git in cygwin are allegedly also
> somewhat incompatible with Git For Windows and on *nix platforms
> the resolution of the timestamps may differ.
Ralf Thielow wrote:
This fixes some minor issues and improves the
German translation a bit. The following things
were changed:
- use complete sentences in option related messages
- translate "use" consistently as "verwendet"
- don't translate "make sense" as "macht Sinn"
While your translations
Brandon Casey wrote:
> --- /dev/null
> +++ b/t/t3511-cherry-pick-x.sh
> @@ -0,0 +1,111 @@
[...]
> + test_commit "$mesg_one_line" foo b mesg-one-line &&
> + git reset --hard initial &&
> + test_commit "$mesg_no_footer" foo b mesg-no-footer &&
> + git reset --hard initial &&
> +
Le 22/01/2013 05:31, Junio C Hamano a écrit :
Jeff King writes:
>
>> I really hate to suggest this, but should it be more like:
>>
>> if test -z "$FAKE_COMMAND_LIST"; then __git_cmdlist() { git help -a
>> | egrep '^ [a-zA-Z0-9]' } else __git_cmdlist() { printf '%s'
>> "$FAKE_COMMAND_LIST" } fi
Brandon Casey wrote:
> The part of test_commit() may not be appropriate for a tag name.
> So let's allow test_commit to accept a fourth argument to specify the tag
> name.
Yes!
[...]
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -135,12 +135,13 @@ test_pause () {
>
82 matches
Mail list logo
