[PATCHv2] submodule--helper: initial clone learns retry logic

Each submodule that is attempted to be cloned, will be retried once in case of failure after all other submodules were cloned. This helps to mitigate ephemeral server failures and increases chances of a reliable clone of a repo with hundreds of submodules immensely. Signed-off-by: Stefan Beller

Re: [PATCH] write_or_die: remove the unused write_or_whine() function

On Thu, Jun 09, 2016 at 11:52:22PM +0100, Ramsay Jones wrote: > > Signed-off-by: Ramsay Jones > --- > > Hi Junio, > > Commit f0bca72d ("send-pack: use buffered I/O to talk to pack-objects", > 08-06-2016) removed the last use of write_or_whine(). I had intended to

Re: [PATCH 1/2] submodule--helper: initial clone learns retry logic

On Thu, Jun 9, 2016 at 1:40 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Stefan Beller writes: >> >>> instead. But that is still unspecified, so we rather go with >>> >>> static int compare_ce(const void *one, const void *two,

Re: [PATCH] Adds *~ to the .gitignore

On Thu, Jun 09, 2016 at 03:48:12PM -0700, Junio C Hamano wrote: > As I said, however, I could support a move to add some selected > small number of common file extensions, as long as we have some > (social) mechanism to avoid churning this file every time somebody > new comes and complains their

[PATCH] write_or_die: remove the unused write_or_whine() function

Signed-off-by: Ramsay Jones --- Hi Junio, Commit f0bca72d ("send-pack: use buffered I/O to talk to pack-objects", 08-06-2016) removed the last use of write_or_whine(). I had intended to include this 'commit citation' in the commit message, but until it reaches the

Re: [PATCH] Adds *~ to the .gitignore

Jeff King writes: > On Thu, Jun 09, 2016 at 02:21:55PM -0700, Junio C Hamano wrote: > >> Lars Vogel writes: >> >> > This helps contributors (like me) using editors which automatically create >> > ~ copies of the changed data >> > >> > Signed-off-by: Lars

Re: [PATCH] send-pack: use buffered I/O to talk to pack-objects

On 09/06/16 18:12, Jeff King wrote: > On Thu, Jun 09, 2016 at 03:34:59PM +0100, Ramsay Jones wrote: > >> Just FYI, this patch removes the last use of write_or_whine() - should it >> be removed? > > That sounds reasonable. Want to do a patch on top? OK, will do. ATB, Ramsay Jones -- To

Re: [PATCH v2 63/94] builtin/apply: make apply_all_patches() return -1 on error

On Wed, Jun 8, 2016 at 7:44 PM, Eric Sunshine wrote: > On Wed, Jun 8, 2016 at 12:37 PM, Christian Couder > wrote: >> On Mon, May 16, 2016 at 5:44 AM, Eric Sunshine >> wrote: >>> On Wed, May 11, 2016 at 9:17 AM,

Re: [PATCH 2/2] bisect--helper: `check_expected_revs` shell function in C

On Wed, Jun 8, 2016 at 11:24 AM, Pranit Bauva wrote: > Reimplement the `check_expected_revs` shell function in C and add a > `--check-expected-revs` subcommand to `git bisect--helper` to call it > from git-bisect.sh . > [...] > Signed-off-by: Pranit Bauva

Re: [PATCH 05/38] refs: create a base class "ref_store" for files_ref_store

Am 07.06.2016 um 18:31 schrieb Junio C Hamano: > This is a tangent, but your series that ends at 4aa2c475 (grep: -W: > don't extend context to trailing empty lines, 2016-05-28) does not > seem to have much effect when viewing the change to refs.c this > patch makes (it modifies a function in an

Re: [PATCH 1/2] bisect--helper: `is_expected_rev` shell function in C

On Thu, Jun 9, 2016 at 5:33 PM, Eric Sunshine wrote: > On Wed, Jun 8, 2016 at 11:24 AM, Pranit Bauva wrote: >> + strbuf_trim(_hex); >> + return !strcmp(actual_hex.buf, expected_hex); > > Thus, it only ever gets to this point if the

Re: [PATCH] Adds *~ to the .gitignore

On Thu, Jun 09, 2016 at 02:21:55PM -0700, Junio C Hamano wrote: > Lars Vogel writes: > > > This helps contributors (like me) using editors which automatically create > > ~ copies of the changed data > > > > Signed-off-by: Lars Vogel > > --- > >

Re: [PATCH 1/2] bisect--helper: `is_expected_rev` shell function in C

On Wed, Jun 8, 2016 at 11:24 AM, Pranit Bauva wrote: > Reimplement `is_expected_rev` shell function in C. This will further be > called from `check_expected_revs` function. This is a quite small > function thus subcommand facility is redundant. This patch should be

Re: [PATCH] Gitk Inotify support

On Thu, Jun 9, 2016 at 2:12 PM, Florian Schüller wrote: > Hi > Is this correct to send possible gitk patches here? or should I send > them to Paul Mackerras somehow? I cc'd Paul for you :) > > Anyway I just wanted that gitk automatically updates while I'm working >

Re: [PATCH] Adds *~ to the .gitignore

Lars Vogel writes: > This helps contributors (like me) using editors which automatically create ~ > copies of the changed data > > Signed-off-by: Lars Vogel > --- We deliberately left this out and kept it out of .gitignore for the past 10 years.

[PATCH] Gitk Inotify support

Hi Is this correct to send possible gitk patches here? or should I send them to Paul Mackerras somehow? Anyway I just wanted that gitk automatically updates while I'm working in my terminal Are you interrested? as described in "SubmittingPatches" this patch is based on

[PATCH] Adds *~ to the .gitignore

This helps contributors (like me) using editors which automatically create ~ copies of the changed data Signed-off-by: Lars Vogel --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 05cb58a..13c7403 100644 --- a/.gitignore

Re: [PATCH v2 00/94] libify apply and use lib in am

Am 12.05.2016 um 20:02 schrieb Christian Couder: On Thu, May 12, 2016 at 7:06 PM, Johannes Sixt wrote: Am 11.05.2016 um 15:16 schrieb Christian Couder: This is a patch series about libifying `git apply` functionality, and using this libified functionality in `git am`, so that

Re: [PATCH 1/2] submodule--helper: initial clone learns retry logic

Junio C Hamano writes: > Stefan Beller writes: > >> instead. But that is still unspecified, so we rather go with >> >> static int compare_ce(const void *one, const void *two, void *cb_data) >> { >> const struct cache_entry *ce_one = one, *ce_two = two;

Re: [PATCH 1/2] submodule--helper: initial clone learns retry logic

Stefan Beller writes: > instead. But that is still unspecified, so we rather go with > > static int compare_ce(const void *one, const void *two, void *cb_data) > { > const struct cache_entry *ce_one = one, *ce_two = two; > return strcmp(ce_one->name, ce_two->name); >

Re: [PATCH] Use "working tree" instead of "working directory" for git status

Matthieu Moy writes: > Lars Vogel writes: > >> --- a/wt-status.c >> +++ b/wt-status.c >> @@ -1554,7 +1554,7 @@ void wt_status_print(struct wt_status *s) >> else >> printf(_("nothing to

Re: [PATCH 1/2] submodule--helper: initial clone learns retry logic

On Thu, Jun 9, 2016 at 12:19 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> +static int compare_ce(const void *one, const void *two, void *cb_data) >> +{ >> + const struct cache_entry *ce_one = one, *ce_two = two; >> + return ce_two -

Re: [PATCH] Use "working tree" instead of "working directory" for git status

Lars Vogel writes: > --- a/wt-status.c > +++ b/wt-status.c > @@ -1554,7 +1554,7 @@ void wt_status_print(struct wt_status *s) > else > printf(_("nothing to commit\n")); > } else > -

Re: [PATCHv4] Documentation: triangular workflow

From: "Jordan DE GEA" Currently, triangular workflow can be configured, but there is no documentation about it. A documentation is useful to keep configuration possibilities up-to-date. A new subsection is created in gitworkflow. Signed-off-by: Michael Haggerty

Re: [PATCH 1/2] submodule--helper: initial clone learns retry logic

Stefan Beller writes: > +static int compare_ce(const void *one, const void *two, void *cb_data) > +{ > + const struct cache_entry *ce_one = one, *ce_two = two; > + return ce_two - ce_one; > +} This would work in practice, but I suspect that this is not ANSI-C kosher;

Trouble installing Git on El Capitan for Mac

Hello, I have had considerable trouble with getting to the second step of using the terminal command to return anything but version not found. It says it is in usr/local/bin but can’t seem to get any further. I have looked for online help but nothing seems to work. Please advise. I am a

[PATCH 0/2] Dealing with a lot of submodules

We have a test repo with about 500 submodules, and I noticed some problems when cloning this repo. This is a series that helps dealing with that repo in two ways: * When having 500 submodules, you have to perform 500 clones. This makes an ephemeral error 500 times more likely. To cope with

[PATCH 2/2] submodule update: continue when a clone fails

In 15ffb7cde48 (2011-06-13, submodule update: continue when a checkout fails), we reasoned it is ok to continue, when there is not much of a mental burden by the failure. If a recursive submodule fails to clone because a .gitmodules file is broken (e.g. : fatal: No url found for submodule path

[PATCH 1/2] submodule--helper: initial clone learns retry logic

Each submodule that is attempted to be cloned, will be retried once in case of failure after all other submodules were cloned. This helps to mitigate ephemeral server failures and increases chances of a reliable clone of a repo with hundreds of submodules immensely. The choice of the priority

Re: [PATCH] Use "working tree" instead of "working directory" for git status

Thanks updated patch on its way. On Thu, Jun 9, 2016 at 7:55 PM, Eric Sunshine wrote: > On Thu, Jun 9, 2016 at 1:46 PM, Lars Vogel wrote: >> Working directory can be easily confused with the current directory. >> In one of my patches I already

[PATCH] Use "working tree" instead of "working directory" for git status

Working directory can be easily confused with the current directory. In one of my patches I already updated the usage of working directory with working tree for the man page but I noticed that git status also uses this incorrect term. Signed-off-by: Lars Vogel ---

Re: [PATCH 5/5] attr.c: always pass check[] to collect_some_attrs()

Stefan Beller writes: >> static void collect_some_attrs(const char *path, int pathlen, >> - struct git_attr_check *check) >> + struct git_attr_check *check, int collect_all) > > I think it may be better to have a

Re: [PATCH] Use "working tree" instead of "working directory" for git status

On Thu, Jun 9, 2016 at 1:46 PM, Lars Vogel wrote: > Working directory can be easily confused with the current directory. > In one of my patches I already updated the usage of working directory > with working tree for the man page but I noticed that git status also > uses

[PATCH] Use "working tree" instead of "working directory" for git status

Working directory can be easily confused with the current directory. In one of my patches I already updated the usage of working directory with working tree for the man page but I noticed that git status also uses this incorrect term. --- po/bg.po| 2 +- po/ca.po| 2 +- po/de.po| 2 +-

Re: [PATCH v2 4/4] bundle v3: the beginning

On Thu, Jun 09, 2016 at 03:53:26PM +0700, Duy Nguyen wrote: > > Yes. To me, this was always about punting large blobs from the clones. > > Basically the way git-lfs and other tools work, but without munging your > > history permanently. > > Makes sense. If we keep all trees and commits locally,

Re: [PATCH] send-pack: use buffered I/O to talk to pack-objects

Junio C Hamano writes: > Matthieu Moy writes: > >> Jeff King writes: >> >>> --- a/send-pack.c >>> +++ b/send-pack.c >>> @@ -36,18 +36,15 @@ int option_parse_push_signed(const struct option *opt, >>> die("bad %s argument: %s",

What's cooking in git.git (Jun 2016, #03; Thu, 9)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The tip of 'pu' is not expected

Re: [PATCH] send-pack: use buffered I/O to talk to pack-objects

On Thu, Jun 09, 2016 at 09:40:42AM -0700, Junio C Hamano wrote: > >>for (i = 0; i < extra->nr; i++) > >> - if (!feed_object(extra->sha1[i], po.in, 1)) > >> - break; > >> + feed_object(extra->sha1[i], po_in, 1); > > > > I may have missed the obvious, but

Re: [PATCH] send-pack: use buffered I/O to talk to pack-objects

On Thu, Jun 09, 2016 at 03:34:59PM +0100, Ramsay Jones wrote: > Just FYI, this patch removes the last use of write_or_whine() - should it > be removed? That sounds reasonable. Want to do a patch on top? -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a

Re: [PATCH v2] builtin/commit.c: memoize git-path for COMMIT_EDITMSG

Pranit Bauva writes: > On Wed, May 25, 2016 at 12:49 AM, Pranit Bauva wrote: >> This is a follow up commit for f932729c (memoize common git-path >> "constant" files, 10-Aug-2015). >> >> The many function calls to git_path() are replaced by >>

Re: [PATCHv4] Documentation: triangular workflow

Jordan DE GEA writes: > +Motivations > +~~~ > +* Allows contributors to work with Git even though they do not have > +write access to **UPSTREAM**. > > +* Allows maintainers to receive code from contributors they may not > +trust. I somehow don't think

Re: [PATCH] send-pack: use buffered I/O to talk to pack-objects

Matthieu Moy writes: > Jeff King writes: > >> --- a/send-pack.c >> +++ b/send-pack.c >> @@ -36,18 +36,15 @@ int option_parse_push_signed(const struct option *opt, >> die("bad %s argument: %s", opt->long_name, arg); >> } >> >> -static int

Re: [PATCH 2/4] Resurrect "diff-lib.c: adjust position of i-t-a entries in diff"

Hi Duy, On Mon, 6 Jun 2016, Nguyễn Thái Ngọc Duy wrote: > diff --git a/diff.h b/diff.h > index b497078..9e42556 100644 > --- a/diff.h > +++ b/diff.h > @@ -92,6 +92,7 @@ typedef struct strbuf *(*diff_prefix_fn_t)(struct > diff_options *opt, void *data) > #define DIFF_OPT_FUNCCONTEXT (1

Re: [PATCH v2 12/13] dir_iterator: new API for iterating over a directory tree

Michael Haggerty writes: > Given that ref-iterators is in next but also that you will soon be > rewinding next, would you like these tweaks as a re-roll of the branch, > as fixup patches to squash on top, or as a new patch series to be > administered separately? A re-roll

Re: [PATCH 05/38] refs: create a base class "ref_store" for files_ref_store

Michael Haggerty writes: >>> + >>> +static struct ref_store *main_ref_store = NULL; >>> + >>> +static struct ref_store *submodule_ref_stores = NULL; >> >> Let's let BSS take care of these initialization. > > I like the `= NULL` because it expresses "yes, I care about the

Re: [PATCH 2/5] t1404: document function test_update_rejected

Michael Haggerty writes: > On 06/07/2016 06:57 PM, Johannes Sixt wrote: >> Am 07.06.2016 um 13:50 schrieb Michael Haggerty: >>> test_update_rejected () { >>> +local prefix before pack create error && >> >> Do we want to add more of unportable 'local' declarations? >

Re: [PATCH 37/38] refs: make lock generic

On 06/07/2016 07:50 PM, Junio C Hamano wrote: > [...] Thanks for all your comments, Junio. I've pushed a revised version of the patch series to my GitHub fork [1] as branch "ref-store", but I'll wait for a little longer to see if there are more comments on the list before sending a re-roll.

Re: [PATCH 2/5] t1404: document function test_update_rejected

On 06/07/2016 06:57 PM, Johannes Sixt wrote: > Am 07.06.2016 um 13:50 schrieb Michael Haggerty: >> test_update_rejected () { >> +local prefix before pack create error && > > Do we want to add more of unportable 'local' declarations? Sorry, I forgot that `local` is not in the POSIX

Re: [PATCH 37/38] refs: make lock generic

On 06/07/2016 07:50 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> From: David Turner >> >> Instead of including a files-backend-specific struct ref_lock, change >> the generic ref_update struct to include a void pointer that backends

Re: [PATCH 34/38] refs: add method for delete_refs

On 06/07/2016 07:43 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> From: David Turner >> >> In the file-based backend, delete_refs has some special optimization >> to deal with packed refs. In other backends, we might be able to make

Re: [PATCH 02/38] rename_ref_available(): add docstring

Michael Haggerty writes: > I propose to change the parameter names to `old_refname` and > `new_refname` and to change the docstring to > ... > Does that sound good? Yes. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

Re: [PATCH 23/38] refs: make peel_ref() virtual

On 06/07/2016 07:36 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> For now it only supports the main reference store. > > Isn't this comment applicable to a handful of recent changes that > made other things virtual, too? Just wondering if I am missing >

Re: [PATCH 21/38] refs: make pack_refs() virtual

On 06/07/2016 07:35 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> Signed-off-by: Michael Haggerty >> --- >> refs.c | 7 +++ >> refs/files-backend.c | 6 -- >> refs/refs-internal.h | 4 >> 3 files changed, 15

Re: [PATCH 17/38] resolve_gitlink_ref(): avoid memory allocation in many cases

On 06/07/2016 07:29 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> If we don't have to strip trailing '/' from the submodule path, then >> don't allocate and copy the submodule name. > > Makes sense. > >> int resolve_gitlink_ref(const char *path, const char

Re: [PATCH] send-pack: use buffered I/O to talk to pack-objects

On 09/06/16 13:10, Matthieu Moy wrote: > Jeff King writes: > >> --- a/send-pack.c >> +++ b/send-pack.c >> @@ -36,18 +36,15 @@ int option_parse_push_signed(const struct option *opt, >> die("bad %s argument: %s", opt->long_name, arg); >> } >> >> -static int

Re: [PATCH 05/38] refs: create a base class "ref_store" for files_ref_store

On 06/07/2016 07:03 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> We want ref_stores to be polymorphic, so invent a base class of which >> files_ref_store is a derived class. For now there is a one-to-one >> relationship between ref_stores and submodules. > >

Re: [PATCH 02/38] rename_ref_available(): add docstring

On 06/07/2016 08:10 PM, Junio C Hamano wrote: > Michael Haggerty writes: > >> From: David Turner >> >> Signed-off-by: David Turner >> Signed-off-by: Junio C Hamano >> Signed-off-by: Michael Haggerty

Re: [PATCH] refs: mark the file-local vtable symbols as static

On 06/08/2016 08:55 PM, Junio C Hamano wrote: > Ramsay Jones writes: > >> Signed-off-by: Ramsay Jones >> --- >> >> Hi Michael, Junio, >> >> I would normally ask you to squash this into the relevant patch when >> you next re-roll your

Re: [PATCH v2 12/13] dir_iterator: new API for iterating over a directory tree

On 06/09/2016 01:46 PM, Michael Haggerty wrote: > On 06/07/2016 07:13 AM, Eric Sunshine wrote: >> [...] > Thanks for all your great comments! Junio, Given that ref-iterators is in next but also that you will soon be rewinding next, would you like these tweaks as a re-roll of the branch, as fixup

[PATCHv4] Documentation: triangular workflow

Currently, triangular workflow can be configured, but there is no documentation about it. A documentation is useful to keep configuration possibilities up-to-date. A new subsection is created in gitworkflow. Signed-off-by: Michael Haggerty Signed-off-by: Matthieu Moy

Re: [PATCH] send-pack: use buffered I/O to talk to pack-objects

Jeff King writes: > --- a/send-pack.c > +++ b/send-pack.c > @@ -36,18 +36,15 @@ int option_parse_push_signed(const struct option *opt, > die("bad %s argument: %s", opt->long_name, arg); > } > > -static int feed_object(const unsigned char *sha1, int fd, int negative) >

Re: [PATCH v4 6/6] send-email: add option --cite to quote the message body

Samuel GROOT writes: > If used with `in-reply-to=`, cite the message body of the given > email file. Otherwise, do nothing. It should at least warn when --in-reply-to= is not given (either no --in-reply-to or --in-reply-to=). I don't see any use-case where a user

Re: [RFC/PATCH] verify-tag: add --check-name flag

Junio C Hamano venit, vidit, dixit 08.06.2016 20:43: > Santiago Torres writes: > >> Sorry I'm trying to follow this. Would it be best to then have >> >> verify-tag [--check-name=tagname] (tag-ref|tag-name|sha1)? >> >> and >> >> tag -v [--check-name] (tag-name) >> >> Or

Re: [PATCH v2 12/13] dir_iterator: new API for iterating over a directory tree

On 06/07/2016 07:13 AM, Eric Sunshine wrote: > On Fri, Jun 3, 2016 at 8:33 AM, Michael Haggerty wrote: >> The iterator interface is modeled on that for references, though no >> vtable is necessary because there is (so far?) only one type of >> dir_iterator. >> [...] > >

Re: [PATCH v2] builtin/commit.c: memoize git-path for COMMIT_EDITMSG

Hey Jeff, On Thu, Jun 9, 2016 at 12:28 PM, Jeff King wrote: > On Tue, Jun 07, 2016 at 08:25:17PM +0530, Pranit Bauva wrote: > >> On Wed, May 25, 2016 at 12:49 AM, Pranit Bauva >> wrote: >> > This is a follow up commit for f932729c (memoize common git-path

Re: [PATCH v4 5/6] send-email: --in-reply-to= populate header fields

Samuel GROOT writes: > diff --git a/Documentation/git-send-email.txt > b/Documentation/git-send-email.txt > index edbba3a..21776f0 100644 > --- a/Documentation/git-send-email.txt > +++ b/Documentation/git-send-email.txt > @@ -84,13 +84,16 @@ See the CONFIGURATION

Re: [PATCH v2 4/4] bundle v3: the beginning

On Wed, Jun 8, 2016 at 11:19 PM, Jeff King wrote: > On Wed, Jun 08, 2016 at 05:44:06PM +0700, Duy Nguyen wrote: > >> On Wed, Jun 8, 2016 at 3:23 AM, Jeff King wrote: >> > Because this "external odb" essentially acts as a git alternate, we >> > would hit it only when

Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison

On 06/09/16 07:51, Matthieu Moy wrote: > Junio C Hamano writes: > >> Tom Russello writes: >> >>> +# Check if two files have the same content, non-order sensitive >>> +test_cmp_noorder () { >>> + sort $1 >$1; >> >> Here is what I think happens:

Re: [PATCH v2] builtin/commit.c: memoize git-path for COMMIT_EDITMSG

On Tue, Jun 07, 2016 at 08:25:17PM +0530, Pranit Bauva wrote: > On Wed, May 25, 2016 at 12:49 AM, Pranit Bauva wrote: > > This is a follow up commit for f932729c (memoize common git-path > > "constant" files, 10-Aug-2015). > > > > The many function calls to git_path() are

Re: [PATCH v4 4/6] send-email: create email parser subroutine

On Wed, Jun 8, 2016 at 7:54 PM, Samuel GROOT wrote: > On 06/08/2016 10:17 PM, Junio C Hamano wrote: >> Eric Sunshine writes: >>> An embedded CR probably shouldn't happen, but I'm not convinced that >>> folding it out is a good idea. I would

Re: [PATCH v4 3/6] send-email: shorten send-email's output

Samuel GROOT writes: > @@ -647,10 +647,10 @@ test_expect_success $PREREQ '--suppress-cc=all' ' > test_expect_success $PREREQ 'setup expect' " > cat >expected-suppress-body <<\EOF > 0001-Second.patch > -(mbox) Adding cc: A from line 'From: A

Re: [PATCH v3 3/6] t9001: shorten send-email's output

Tom Russello writes: > Messages displayed by `send-email` should be shortened to avoid displaying > unnecesseray informations. We usually use imperative tone in commit messages: Shorten messages displayed by `send-email` to avoid displaying unnecessary

Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison

Samuel GROOT writes: > On 06/08/2016 06:09 PM, Junio C Hamano wrote: >> Samuel GROOT writes: >> >>> Actually we had issues when trying to refactor send-email's email >>> parsing loop [1]. Email addresses in output file