While looking for a way to expand the URL of a remote
that uses a 'url..insteadOf' config option I stumbled
over the undocumented '--get-url' option of 'git ls-remote'.
This adds some minimum documentation for that option.
And while at it, also add that option to the '-h' output.
Signed-off-by: S
David Aguilar writes:
> Tags in git are meant to be immutable. You can delete them, but
> you shouldn't. That's not really how they are intended to be
> used.
>
> gitk avoids re-reading that information because the normal,
> typical use case is that the tag messages do not change.
>
> It would
On Thu, Sep 6, 2012 at 11:17 AM, Tim McCormack wrote:
> If a tag that gitk knows about is deleted and recreated with a
> different message, gitk still shows the old message after any
> combination of refresh, reload, and reread refs.
>
> git-gui version 0.13.0.8.g8f85
>
> Reproduce:
> 1. git tag -
Excerpts from Junio C Hamano's message of Thu Sep 06 21:33:20 -0400 2012:
Hi Junio,
> > identifiers generated from keys like:
> >
> > url./some/really/long/path.insteadOf
> >
> > could overrun the current limit. It's not a common case, of course,
> > or this issue would have been found sooner.
Ben Walton writes:
> Key names have a length limit defined by MAXNAME in config.c. When
> reading the config file, we reserve half of this limit for the section
> identifier and the other half for the key name within that section.
>
> For example, if setting a key named url.foo.insteadOf, url.fo
On Fri, Sep 7, 2012 at 12:34 AM, Junio C Hamano wrote:
> Modulo that I suspect you could get rid of offset_1st_component()
> altogether and has_dos_drive_prefix() return the length of the "d:"
> or "//d" part (which needs to be copied literally regardless of the
> "normalization"), what you sugges
Key names have a length limit defined by MAXNAME in config.c. When
reading the config file, we reserve half of this limit for the section
identifier and the other half for the key name within that section.
For example, if setting a key named url.foo.insteadOf, url.foo may use
at most half of MANX
Michael Haggerty writes:
> Signed-off-by: Michael Haggerty
> ---
I think I asked why this matters (iow, why it is the right thing to
do to reject an empty string, instead of treating it as "the current
directory") in the previous round. I would have expected to find
the answer be above the S-o
mhag...@alum.mit.edu writes:
> From: Michael Haggerty
>
> There is currently a bug: if passed an absolute top-level path that
> doesn't exist (e.g., "/foo") it incorrectly interprets the path as a
> relative path (e.g., returns "$(pwd)/foo"). So mark the test as
> failing.
>
> Signed-off-by: Mic
Adjusted for Windows by: Johannes Sixt
Signed-off-by: Michael Haggerty
---
t/t0060-path-utils.sh | 18 ++
1 file changed, 18 insertions(+)
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index 30361f9..e40f764 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-uti
There is currently a bug: if passed an absolute top-level path that
doesn't exist (e.g., "/foo") it incorrectly interprets the path as a
relative path (e.g., returns "$(pwd)/foo"). So mark the test as
failing.
These tests are skipped on Windows because test-path-utils operates on
a DOS-style abso
The change has two points:
1. Do not strip off a leading slash, because that erroneously turns an
absolute path into a relative path.
2. Do not remove slashes from groups of multiple slashes; instead let
chdir() handle them. It could be, for example, that it wants to
leave leading doubl
Signed-off-by: Michael Haggerty
---
abspath.c | 4 +++-
t/t0060-path-utils.sh | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/abspath.c b/abspath.c
index f04ac18..5d62430 100644
--- a/abspath.c
+++ b/abspath.c
@@ -123,7 +123,9 @@ const char *absolute_path(const
Signed-off-by: Michael Haggerty
---
abspath.c | 3 +++
t/t0060-path-utils.sh | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/abspath.c b/abspath.c
index 5d62430..3e8325c 100644
--- a/abspath.c
+++ b/abspath.c
@@ -35,6 +35,9 @@ const char *real_path(const char *p
It doesn't, so mark the test as failing.
Signed-off-by: Michael Haggerty
---
t/t0060-path-utils.sh | 4
1 file changed, 4 insertions(+)
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index 924aa60..1118056 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -144,6
It doesn't, so mark the test as failing.
Signed-off-by: Michael Haggerty
---
t/t0060-path-utils.sh | 4
1 file changed, 4 insertions(+)
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index c8db144..d91e516 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -140,6
Suggested by: Johannes Sixt
Signed-off-by: Michael Haggerty
---
t/t-basic.sh | 18 --
t/t0060-path-utils.sh | 19 +++
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/t/t-basic.sh b/t/t-basic.sh
index ccb5435..ae6a3f0 100755
--- a
Second version of patches, incorporating gratefully received advice
from Hannes:
* Moved existing tests of real_path() from t to t0060, and add new
tests to t0060 instead of t.
* Adjusted the regexp used to construct a top-level directory that is
needed for tests.
* Skip some tests w
On 09/05/2012 10:40 AM, Johannes Sixt wrote:
> Am 9/4/2012 10:14, schrieb mhag...@alum.mit.edu:
>> From: Michael Haggerty
>>
>> These tests already pass, but make sure they don't break in the
>> future.
>>
>> Signed-off-by: Michael Haggerty
>> ---
>>
>> It would be great if somebody would check w
On Thu, Sep 6, 2012 at 2:21 PM, Junio C Hamano wrote:
> We may pick up additional recipients from the format-patch output
> files we are sending, in which case it is perfectly valid to leave
> the @initial_to empty when the prompt asks. We may want to start
> a new discussion thread without reply
On Thu, Sep 6, 2012 at 1:03 PM, Junio C Hamano wrote:
>
> If you let $to to go empty with the first hunk of your patch, where
> does the mail eventually go? Does anybody later in the code decide
> to add some recipient? If there is a reason why an empty input is a
> valid here, I think there is
We may pick up additional recipients from the format-patch output
files we are sending, in which case it is perfectly valid to leave
the @initial_to empty when the prompt asks. We may want to start
a new discussion thread without replying to anything, and it is
valid to leave $initial_reply_to emp
On 09/05/2012 10:40 AM, Johannes Sixt wrote:
> Am 9/4/2012 10:14, schrieb mhag...@alum.mit.edu:
>> From: Michael Haggerty
>>
>> There is currently a bug: if passed an absolute top-level path that
>> doesn't exist (e.g., "/foo") it incorrectly interprets the path as a
>> relative path (e.g., return
Nguyen Thai Ngoc Duy writes:
>>> I'm not great at naming. And path_excluded() cannot be reused to avoid
>>> problems with other ongoing series if any. So path_is_excluded()?
>>
>> is_path_excluded()?
>
> Good too.
Sure, either would work.
--
To unsubscribe from this list: send the line "unsubscr
There is a strange workaround for SVN-repos, containing directories that
were replaced by symlinks in the past, properly cloned into GIT (with
empty dirs):
You have to import it part-by-part ... i.e. fetch revision 1-3 and then
fetch 4-5:
git svn clone -r 1:3 --preserve-empty-dirs file://`pw
I'm generally very happy with the fuzzy parsing. It's a great feature
that is designed to and in general does save users a lot of time and
thought. In this case I don't think it does. The problems are:
(1) It's not ignoring things it can't understand, it's silently
interpreting them in a useless wa
Stefan Naewe writes:
> While looking for a way to expand the URL of a remote
> that uses a 'url..insteadOf' config option I stumbled
> over the undocumented '--get-url' option of 'git ls-remote'.
> This adds some minimum documentation for that option.
>
> Signed-off-by: Stefan Naewe
> ---
> Doc
Jeffrey Middleton writes:
> In telling someone what date formats git accepts, and how to verify it
> understands, I noticed this weirdness:
>
> $ export TEST_DATE_NOW=`date -u +%s --date='September 10'`;
> ./test-date approxidate now; for i in `seq 1 10`; do ./test-date
> approxidate "$i frobbles
Am 06.09.2012 14:34, schrieb Thomas Gummerer:
> On 09/06, Jan-Marek Glogowski wrote:
>> This adds the test ID (t) prefix to the test result message of
>> all shell tests. This is especially useful when doing a parallel
>> check run, where it's currently quite hard to identify the actual
>> fai
Stephen Boyd writes:
> It works fine for "Who should the emails appear to be from?" but
> beyond that we have "Who should the emails be sent to?" and
> "Message-ID to be used as In-Reply-To for the first email?" which I
> typically just hit enter to. It seems that they have no "default"
> argumen
Enrico Weigelt writes:
>> Enrico Weigelt writes:
>>
>> > * blobs are encrypted with their (original) content hash as
>> > encryption keys
>>
>> What does this even mean?
>>
>> Is it expected that anybody who has access to the repository can
>> learn names of objects (e.g. by running "ls .gi
"W. Trevor King" writes:
> On Wed, Sep 05, 2012 at 10:23:54PM -0700, Junio C Hamano wrote:
>> Really? Would "git log --expand master" be useful?
>
> I'm clearly not an expert on this, but isn't that what
>
> git show-ref master
>
> is for?
But then can't you say the same against "git notes ge
If a tag that gitk knows about is deleted and recreated with a
different message, gitk still shows the old message after any
combination of refresh, reload, and reread refs.
git-gui version 0.13.0.8.g8f85
Reproduce:
1. git tag -a test -m "foo" HEAD
2. Open gitk, see that correct message ("foo") i
Michael J Gruber writes:
> Junio C Hamano venit, vidit, dixit 06.09.2012 07:07:
>> Michael J Gruber writes:
>>
>>> The pre-commit hook is often used to ensure certain properties of each
>>> comitted tree like formatting or coding standards, validity (lint/make)
>>> or code quality (make test).
(Sorry sending this from web interface)
On Wed, Sep 5, 2012 at 8:29 PM, Junio C Hamano wrote:
> Stephen Boyd writes:
>> This is now bugging me if I just hit enter and don't want to specify
>> anything for
>> these headers (I want the defaults or what's in the files already).
>> Can we allow
>> t
Torsten Bögershausen writes:
> I try to re-phrase my question:
>
> Do installations still exist which use e.g. BIG5 or any other
> multi byte encoding which is not UTF-8?
Yes.
> Do we want to support other encodings than ASCII or UTF-8?
> (Because then the screen width needs to be calculate dif
On Sun, Sep 2, 2012 at 11:36 PM, Philip Oakley wrote:
> From: "Junio C Hamano"
> Sent: Sunday, September 02, 2012 8:02 PM
>> "Philip Oakley" writes:
>>> Is there a way to identify the config core.excludesfile if present?
>>> i.e. that it is from that config variable, rather than directory
>>> tr
On Sun, Sep 2, 2012 at 9:35 PM, Junio C Hamano wrote:
> Adam Spiers writes:
>
>> I was browsing stackoverflow the other day and came across this question:
>>
>>
>> http://stackoverflow.com/questions/12144633/which-gitignore-rule-is-ignoring-my-file/
>>
>> A quick google revealed this thread
On Thu, Sep 6, 2012 at 4:05 PM, Nguyen Thai Ngoc Duy wrote:
> On Thu, Sep 6, 2012 at 9:59 PM, Thiago Farina wrote:
>> On Thu, Sep 6, 2012 at 9:13 AM, Nguyen Thai Ngoc Duy
>> wrote:
>>> On Thu, Sep 6, 2012 at 10:21 AM, Junio C Hamano wrote:
Nguyen Thai Ngoc Duy writes:
> We could
Ken Dreyer writes:
> Thanks Andreas for catching that "ref.c" in the comments ought to be
> "refs.c". I've corrected that in this latest version of the patch.
Yeah, thanks, all. Will queue.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@v
Nguyen Thai Ngoc Duy writes:
> Just an idea. We could unify "[a-z]:" and "//host" into "dos root"
> concept. That would teach other code paths about UNC paths too.
> ...
> diff --git a/path.c b/path.c
> index 66acd24..0e4e2d7 100644
> --- a/path.c
> +++ b/path.c
> @@ -498,11 +498,12 @@ const char
While looking for a way to expand the URL of a remote
that uses a 'url..insteadOf' config option I stumbled
over the undocumented '--get-url' option of 'git ls-remote'.
This adds some minimum documentation for that option.
Signed-off-by: Stefan Naewe
---
Documentation/git-ls-remote.txt | 4
On Thu, Sep 6, 2012 at 6:44 PM, Thomas Rast wrote:
> Ralf Thielow writes:
>
>> "(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n"
>> "'current' instead of 'simple' if you sometimes use older versions of Git)"
> [...]
>> +"(Der Modus 'simple' wurde in Git 1.7.11 eingeführt.
Ralf Thielow writes:
> "(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n"
> "'current' instead of 'simple' if you sometimes use older versions of Git)"
[...]
> +"(Der Modus 'simple' wurde in Git 1.7.11 eingeführt. Benutze den
> gleichartigen"
> +" Modus 'current' anstatt '
Certain characters such as "?" can be present in a CVS tag name, but
git does not allow these characters in tags. If git-cvsimport
encounters a CVS tag that git cannot handle, cvsimport will error and
refuse to continue the import beyond that point.
When importing CVS tags, strip all the inappropr
Am 06.09.2012 um 17:36 schrieb Nguyen Thai Ngoc Duy:
> On Thu, Sep 6, 2012 at 2:20 AM, Torsten Bögershausen wrote:
>>> Will that work for non-ASCII encodings?
>>> For ISO-8859-x we can say strlen() == strwidth(),
>>> but for other encodings using multibytes that doesn't work, does it?
>
> BTW i
On Thu, Sep 6, 2012 at 2:20 AM, Torsten Bögershausen wrote:
>> Will that work for non-ASCII encodings?
>> For ISO-8859-x we can say strlen() == strwidth(),
>> but for other encodings using multibytes that doesn't work, does it?
BTW if you are interested in supporting non-utf8 output, you may want
"%s files" gives no sense what "%s" might be. Give translators full
phrases.
"blah blah blah%s\n" where %s is another sentence does not show the real
length of full line. As a result, l10n messages may exceed 80 columns
unintentionally. Make it two sentences.
Signed-off-by: Nguyễn Thái Ngọc Duy
Il 06/09/2012 16:44, Joachim Schmitz ha scritto:
>> > Yes, it's an usleep(autocorrect * 10) basically (poll takes
>> > milliseconds, not micro).
> OK, it is _supposed_ to do this usleep(), but is does not, as poll() returns
> early with EFAULT in this case:
> /* EFAULT is not necessary to im
On Thu, Sep 06, 2012 at 12:12:42PM +0200, norbert.nemec wrote:
> The option should either be rejected or do *something* documented and
> useful. Ideally, it should result in behavior that matches 'git log
> --follow' as closely as possible. So maybe, it should be a synonym
> for a certain number o
On Thu, Sep 06, 2012 at 02:34:00PM +0200, Thomas Gummerer wrote:
> On 09/06, Jan-Marek Glogowski wrote:
> > This adds the test ID (t) prefix to the test result message of
> > all shell tests. This is especially useful when doing a parallel
> > check run, where it's currently quite hard to ide
On Thu, Sep 6, 2012 at 9:59 PM, Thiago Farina wrote:
> On Thu, Sep 6, 2012 at 9:13 AM, Nguyen Thai Ngoc Duy
> wrote:
>> On Thu, Sep 6, 2012 at 10:21 AM, Junio C Hamano wrote:
>>> Nguyen Thai Ngoc Duy writes:
>>>
We could introduce exclude_path() and kill path_excluded() then. There
a
On Thu, Sep 6, 2012 at 9:13 AM, Nguyen Thai Ngoc Duy wrote:
> On Thu, Sep 6, 2012 at 10:21 AM, Junio C Hamano wrote:
>> Nguyen Thai Ngoc Duy writes:
>>
>>> We could introduce exclude_path() and kill path_excluded() then. There
>>> are just about 5-6 call sites to replace.
>>
>> The name path_exc
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Thursday, September 06, 2012 4:32 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org; 'Junio C Hamano'; 'Erik Faye-Lund';
> bug-gnu...@gnu.org; rsbec...@nexbridge.com
> Subject: Re: poll() emulation in git
rev-list-options.txt is included in git-rev-list.txt. This makes sure
rev-list man page also shows that, and at one place, together with
equivalent options -n and --max-count.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-log.txt | 6 ++
Documentation/rev-list-options.tx
Il 06/09/2012 16:02, Joachim Schmitz ha scritto:
>
> But is there something that could be done to make git work even without
> poll()?
> It is used in 5 places:
>
> $ grep -n poll\( *.c */*.c
> credential-cache--daemon.c:175: if (poll(&pfd, 1, 1000 * wakeup) < 0) {
> daemon.c:1018: if (
Add tests which make sure that the pre-commit hook is called by 'git
merge' when merge.usePreCommitHook is set, allows/disallows merge
commits depending on its return value and is suppressed by
"--no-verify".
Signed-off-by: Michael J Gruber
---
t/t7503-pre-commit-hook.sh | 62 +++
Analogous to commit, introduce a '--no-verify' option which bypasses the
pre-commit hook. The shorthand '-n' is taken by the (non-existing)
'--no-stat' already.
Signed-off-by: Michael J Gruber
---
Documentation/git-merge.txt | 2 +-
Documentation/githooks.txt | 1 +
Documentation/merge-
git-merge does not honor the pre-commit hook when doing automatic merge
commits, and for compatibility reasons this is going to stay.
Introduce a merge.usePreCommitHook which controls whether an automatic
merge commit invokes pre-commit.
Signed-off-by: Michael J Gruber
---
Documentation/git-mer
Signed-off-by: Michael J Gruber
---
Documentation/git-merge.txt | 5 +
Documentation/githooks.txt | 2 ++
2 files changed, 7 insertions(+)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 20f9228..b3ba8a8 100644
--- a/Documentation/git-merge.txt
+++ b/Documentat
In this second iteration I implement Junio's suggestion: 'git merge' invokes
the pre-commit hook when merge.usePreCommitHook is set to true.
1/4 documents that 'git merge' invokes the prepare-commit-msg hook
unconditionally already.
2-4 are v2 of the previous 1-3.
This leaves aside the issue of
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Wednesday, September 05, 2012 5:26 PM
> To: Joachim Schmitz
> Cc: 'Junio C Hamano'; git@vger.kernel.org; 'Erik Faye-Lund';
> bug-gnu...@gnu.org
> Subject: Re: poll() emulation in git
>
> Il 05/09/2012 15:
Hi,
> > IIRC some people were working on splitted directory objects
> > (eg. for putting subdirs into their own objects), some time ago.
>
> Each directory maps to its own tree object, so a subdirectory is
> stored in its own object. It happened on April 7th, 2005, if not
> earlier.
Ah, great
Hi,
> Enrico Weigelt writes:
>
> > * blobs are encrypted with their (original) content hash as
> > encryption keys
>
> What does this even mean?
>
> Is it expected that anybody who has access to the repository can
> learn names of objects (e.g. by running "ls .git/objects/??/")? If
> so, fro
On 09/04, Ramsay Jones wrote:
>
> Hi Thomas,
>
> The current pu branch is *very* broken on cygwin; practically every
> test fails. A git-bisect session points to:
>
> $ git bisect good
> a4f6670277d5dc0b082139efe162100c6d7a91b8 is the first bad commit
> commit a4f6670277d5dc0b082139e
On 09/06, Jan-Marek Glogowski wrote:
> This adds the test ID (t) prefix to the test result message of
> all shell tests. This is especially useful when doing a parallel
> check run, where it's currently quite hard to identify the actual
> failing test case.
>
> Signed-off-by: Jan-Marek Glogow
All remote subcommands are spelled out words except 'rm'. 'rm', being a
popular UNIX command name, may mislead users that there are also 'ls' or
'mv'. Use 'remove' to fit with the rest of subcommands.
'rm' is still supported and used in the test suite. It's just not
widely advertised.
Signed-off-
Hello everyone,
I've run into a minor bug in the git svn integration. When I run git svn
dcommit with git 1.7.12, it successfully sends the commit to the svn server and
rebases if necessary. However, the svn server has a post commit hook which
runs, and is supposed to return some text to the cl
On Thu, Sep 6, 2012 at 10:21 AM, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> We could introduce exclude_path() and kill path_excluded() then. There
>> are just about 5-6 call sites to replace.
>
> The name path_excluded(... path ...) sounds like it is asking a
> yes/no question "is
On Thu, Sep 6, 2012 at 2:20 AM, Torsten Bögershausen wrote:
> On 09/05/2012 08:15 PM, Torsten Bögershausen wrote:
>>
>> On 04.09.12 12:39, Nguyễn Thái Ngọc Duy wrote:
>>>
>>> +/* return the number of columns of string 's' in current locale */
>>> +int gettext_width(const char *s)
>>> +{
>>> +
This adds the test ID (t) prefix to the test result message of
all shell tests. This is especially useful when doing a parallel
check run, where it's currently quite hard to identify the actual
failing test case.
Signed-off-by: Jan-Marek Glogowski
---
t/t-basic.sh| 28 ++
On 09/06/2012 10:16 AM, Michael J Gruber wrote:
> Michael Haggerty venit, vidit, dixit 05.09.2012 17:30:
>> On 09/05/2012 03:39 PM, Michael J Gruber wrote:
>>> git-merge does not honor the pre-commit hook when doing automatic merge
>>> commits, and for compatibility reasons this is going to stay.
>
Thanks for the explanation.
I actually do not have any clear opinion what it should do. Just that
the current situation is confusing when experimenting and trying to
understand the behavior of git blame and git log: an intuitive option
that is accepted but ignored.
The option should either b
On Thu, Sep 06, 2012 at 09:02:17AM +0200, norbert.nemec wrote:
> 'git blame --follow' seems to be undocumented. The exact behavior is
> not clear to me. Perhaps an alias for some combination of '-C' and
> '-M'? It seems not be be fully consistent with 'git log --follow'.
>
> Could someone clarify
Ken Dreyer writes:
> + # See ref.c for these rules.
> + # Tag cannot contain bad chars. See bad_ref_char in ref.c.
s/ref.c/refs.c/
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for so
Michael Haggerty venit, vidit, dixit 05.09.2012 17:30:
> On 09/05/2012 03:39 PM, Michael J Gruber wrote:
>> git-merge does not honor the pre-commit hook when doing automatic merge
>> commits, and for compatibility reasons this is going to stay.
>>
>> Introduce a pre-merge hook which is called for a
Junio C Hamano venit, vidit, dixit 06.09.2012 07:07:
> Michael J Gruber writes:
>
>> The pre-commit hook is often used to ensure certain properties of each
>> comitted tree like formatting or coding standards, validity (lint/make)
>> or code quality (make test). But merges introduce new commits u
On Wed, Sep 05, 2012 at 10:23:54PM -0700, Junio C Hamano wrote:
> Really? Would "git log --expand master" be useful?
I'm clearly not an expert on this, but isn't that what
git show-ref master
is for? Or is the fact that show-ref returns hashes the more
important feature?
There was a lot of
Hi there,
'git blame --follow' seems to be undocumented. The exact behavior is not
clear to me. Perhaps an alias for some combination of '-C' and '-M'? It
seems not be be fully consistent with 'git log --follow'.
Could someone clarify? Did I miss something?
Greetings,
Norbert
--
To unsubscr
79 matches
Mail list logo
