threads / patch / 10474

patchgit-mailsplit: with maildirs try to process new/ if cur/ is empty

Subject: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

## tl;dr

20 messages between Oct 26, 2007 and Nov 8, 2007. Diffs are folded; open one to read it.

replies: 19people: 9as markdown or json

Gerrit Pape· Oct 26, 2007, 14:15 UTC · lore

When saving patches to a maildir with e.g. mutt, the files are put into the new/ subdirectory of the maildir, not cur/. This makes git-am state "Nothing to do.". This patch lets git-mailsplit fallback to new/ if the cur/ subdirectory is empty.

This was reported by Joey Hess through
 http://bugs.debian.org/447396
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
 Documentation/git-am.txt |    3 ++-
 builtin-mailsplit.c      |    5 +++++
 2 files changed, 7 insertions(+), 1 deletions(-)
Show changes to 2 files +7 −1

Documentation/git-am.txt, builtin-mailsplit.c

diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index e4a6b3a..49f79f6 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -26,7 +26,8 @@ OPTIONS
 <mbox>|<Maildir>...::
 	The list of mailbox files to read patches from. If you do not
 	supply this argument, reads from the standard input. If you supply
-	directories, they'll be treated as Maildirs.
+	directories, they'll be treated as Maildirs, which should contain
+	the patches either in the cur/ subdirectory, or in new/.
 
 -s, --signoff::
 	Add `Signed-off-by:` line to the commit message, using
diff --git a/builtin-mailsplit.c b/builtin-mailsplit.c
index 43fc373..eaf3cbe 100644
--- a/builtin-mailsplit.c
+++ b/builtin-mailsplit.c
@@ -131,6 +131,11 @@ static int split_maildir(const char *maildir, const char *dir,
 	snprintf(curdir, sizeof(curdir), "%s/cur", maildir);
 	if (populate_maildir_list(&list, curdir) < 0)
 		goto out;
+	if (list.nr == 0) {
+		snprintf(curdir, sizeof(curdir), "%s/new", maildir);
+		if (populate_maildir_list(&list, curdir) < 0)
+			goto out;
+	}
 
 	for (i = 0; i < list.nr; i++) {
 		FILE *f;
-- 
1.5.3.4
Fernando J. Pereda· Oct 26, 2007, 16:01 UTC · re: Gerrit Pape · lore

Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

On Fri, Oct 26, 2007 at 02:15:39PM +0000, Gerrit Pape wrote:
Show 8 quoted lines
> When saving patches to a maildir with e.g. mutt, the files are put into
> the new/ subdirectory of the maildir, not cur/.  This makes git-am state
> "Nothing to do.".  This patch lets git-mailsplit fallback to new/ if the
> cur/ subdirectory is empty.
> 
> This was reported by Joey Hess through
>  http://bugs.debian.org/447396
> 
By that reasoning, you should make it parse both cur/ and new/.

This didn't bit me because I always check mails I queue, so they ended up in cur/.

Other than that, ack from me.
- ferdy
-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4
Gerrit Pape· Nov 5, 2007, 12:49 UTC · re: Fernando J. Pereda · lore

When saving patches to a maildir with e.g. mutt, the files are put into the new/ subdirectory of the maildir, not cur/. This makes git-am state "Nothing to do.". This patch lets git-mailsplit additional check new/ after reading cur/.

This was reported by Joey Hess through
 http://bugs.debian.org/447396
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
On Fri, Oct 26, 2007 at 06:01:18PM +0200, Fernando J. Pereda wrote:
> By that reasoning, you should make it parse both cur/ and new/.
Okay.
 builtin-mailsplit.c |   36 ++++++++++++++++++++----------------
 1 files changed, 20 insertions(+), 16 deletions(-)
Show changes to builtin-mailsplit.c +20 −16
diff --git a/builtin-mailsplit.c b/builtin-mailsplit.c
index 74b0470..79e8ee0 100644
--- a/builtin-mailsplit.c
+++ b/builtin-mailsplit.c
@@ -101,19 +101,26 @@ static int populate_maildir_list(struct path_list *list, const char *path)
 {
 	DIR *dir;
 	struct dirent *dent;
+	char name[PATH_MAX];
+	char *sub[] = { "cur", "new" };
+	int i;
 
-	if ((dir = opendir(path)) == NULL) {
-		error("cannot opendir %s (%s)", path, strerror(errno));
-		return -1;
-	}
+	for (i = 0; i < 2; ++i) {
+		snprintf(name, sizeof(name), "%s/%s", path, sub[i]);
+		if ((dir = opendir(name)) == NULL) {
+			error("cannot opendir %s (%s)", name, strerror(errno));
+			return -1;
+		}
 
-	while ((dent = readdir(dir)) != NULL) {
-		if (dent->d_name[0] == '.')
-			continue;
-		path_list_insert(dent->d_name, list);
-	}
+		while ((dent = readdir(dir)) != NULL) {
+			if (dent->d_name[0] == '.')
+				continue;
+			snprintf(name, sizeof(name), "%s/%s", sub[i], dent->d_name);
+			path_list_insert(name, list);
+		}
 
-	closedir(dir);
+		closedir(dir);
+	}
 
 	return 0;
 }
@@ -122,19 +129,17 @@ static int split_maildir(const char *maildir, const char *dir,
 	int nr_prec, int skip)
 {
 	char file[PATH_MAX];
-	char curdir[PATH_MAX];
 	char name[PATH_MAX];
 	int ret = -1;
 	int i;
 	struct path_list list = {NULL, 0, 0, 1};
 
-	snprintf(curdir, sizeof(curdir), "%s/cur", maildir);
-	if (populate_maildir_list(&list, curdir) < 0)
+	if (populate_maildir_list(&list, maildir) < 0)
 		goto out;
 
 	for (i = 0; i < list.nr; i++) {
 		FILE *f;
-		snprintf(file, sizeof(file), "%s/%s", curdir, list.items[i].path);
+		snprintf(file, sizeof(file), "%s/%s", maildir, list.items[i].path);
 		f = fopen(file, "r");
 		if (!f) {
 			error("cannot open mail %s (%s)", file, strerror(errno));
@@ -152,10 +157,9 @@ static int split_maildir(const char *maildir, const char *dir,
 		fclose(f);
 	}
 
-	path_list_clear(&list, 1);
-
 	ret = skip;
 out:
+	path_list_clear(&list, 1);
 	return ret;
 }
 
-- 
1.5.3.5
Jakub Narebski· Nov 5, 2007, 12:58 UTC · re: Gerrit Pape · lore

Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

[Cc: Gerrit Pape <pape@smarden.org>, git@vger.kernel.org]
Gerrit Pape wrote:
> +       char *sub[] = { "cur", "new" };
[...]
> +       for (i = 0; i < 2; ++i) {

Wouldn't it be better to use sizeof(sub)/sizeof(sub[0]) or it's macro equivalent ARRAY_SIZE(sub) instead of hardcoding 2 to avoid errors?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Jeff King· Nov 5, 2007, 21:26 UTC · re: Gerrit Pape · lore

Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

On Mon, Nov 05, 2007 at 12:49:20PM +0000, Gerrit Pape wrote:
> On Fri, Oct 26, 2007 at 06:01:18PM +0200, Fernando J. Pereda wrote:
> > By that reasoning, you should make it parse both cur/ and new/.
> Okay.
Isn't the subject line now wrong?
-Peff
Alex Riesen· Nov 5, 2007, 22:52 UTC · re: Gerrit Pape · lore

Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

Gerrit Pape, Mon, Nov 05, 2007 13:49:20 +0100:
Show 6 quoted lines
> +	for (i = 0; i < 2; ++i) {
> +		snprintf(name, sizeof(name), "%s/%s", path, sub[i]);
> +		if ((dir = opendir(name)) == NULL) {
> +			error("cannot opendir %s (%s)", name, strerror(errno));
> +			return -1;
> +		}

Why is missing "cur" (or "new", for that matter) a fatal error? Why is it error at all? How about just ignoring the fact?

Michael Cohen· Nov 6, 2007, 01:41 UTC · re: Alex Riesen · lore

Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

On Nov 5, 2007, at 5:52 PM, Alex Riesen wrote:
Show 10 quoted lines
> Gerrit Pape, Mon, Nov 05, 2007 13:49:20 +0100:
>> +	for (i = 0; i < 2; ++i) {
>> +		snprintf(name, sizeof(name), "%s/%s", path, sub[i]);
>> +		if ((dir = opendir(name)) == NULL) {
>> +			error("cannot opendir %s (%s)", name, strerror(errno));
>> +			return -1;
>> +		}
>
> Why is missing "cur" (or "new", for that matter) a fatal error?
> Why is it error at all? How about just ignoring the fact?
In Maildir format, cur and new hold the mails. :P
-mjc
Alex Riesen· Nov 6, 2007, 07:28 UTC · re: Michael Cohen · lore

Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

Michael Cohen, Tue, Nov 06, 2007 02:41:56 +0100:
Show 13 quoted lines
> On Nov 5, 2007, at 5:52 PM, Alex Riesen wrote:
>
>> Gerrit Pape, Mon, Nov 05, 2007 13:49:20 +0100:
>>> +	for (i = 0; i < 2; ++i) {
>>> +		snprintf(name, sizeof(name), "%s/%s", path, sub[i]);
>>> +		if ((dir = opendir(name)) == NULL) {
>>> +			error("cannot opendir %s (%s)", name, strerror(errno));
>>> +			return -1;
>>> +		}
>>
>> Why is missing "cur" (or "new", for that matter) a fatal error?
>> Why is it error at all? How about just ignoring the fact?
> In Maildir format, cur and new hold the mails. :P

So? Why *STOP* reading the mails if just one of the directories could not be opened? IOW, I suggest:

+ for (i = 0; i < 2; ++i) { + snprintf(name, sizeof(name), "%s/%s", path, sub[i]); + dir = opendir(name); + if (!dir) + continue;

Jeff King· Nov 6, 2007, 07:51 UTC · re: Alex Riesen · lore

Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

On Tue, Nov 06, 2007 at 08:28:31AM +0100, Alex Riesen wrote:
> > In Maildir format, cur and new hold the mails. :P
> 
> So? Why *STOP* reading the mails if just one of the directories could
> not be opened? IOW, I suggest:

Because you are then trying to apply a patch series with some patches potentially missing? Continuing only on errno == ENOENT seems prudent.

-Peff
Johannes Schindelin· Nov 6, 2007, 11:01 UTC · re: Jeff King · lore

Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

Hi,
On Tue, 6 Nov 2007, Jeff King wrote:
Show 9 quoted lines
> On Tue, Nov 06, 2007 at 08:28:31AM +0100, Alex Riesen wrote:
> 
> > > In Maildir format, cur and new hold the mails. :P
> > 
> > So? Why *STOP* reading the mails if just one of the directories could 
> > not be opened? IOW, I suggest:
> 
> Because you are then trying to apply a patch series with some patches 
> potentially missing? Continuing only on errno == ENOENT seems prudent.

I fail to see how the absence of one of cur/ or new/ can lead to the absence of patches. You could forget to save some patches, yes, but the presence of cur/ and new/ is no indicator for that.

Ciao, Dscho

Jeff King· Nov 6, 2007, 15:47 UTC · re: Johannes Schindelin · lore

Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
Show 9 quoted lines
> > > So? Why *STOP* reading the mails if just one of the directories could 
> > > not be opened? IOW, I suggest:
> > 
> > Because you are then trying to apply a patch series with some patches 
> > potentially missing? Continuing only on errno == ENOENT seems prudent.
> 
> I fail to see how the absence of one of cur/ or new/ can lead to the 
> absence of patches.  You could forget to save some patches, yes, but the 
> presence of cur/ and new/ is no indicator for that.

Read my message again. Alex is proposing ignoring errors in opening the directories; I am proposing ignoring such errors _only_ when the error is that the directory does not exist.

IOW, if there is some other error in opening the directory, it should be fatal, because you might be missing patches.

-Peff
Johannes Schindelin· Nov 6, 2007, 15:51 UTC · re: Jeff King · lore

Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

Hi,
On Tue, 6 Nov 2007, Jeff King wrote:
Show 18 quoted lines
> On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
> 
> > > > So? Why *STOP* reading the mails if just one of the directories could 
> > > > not be opened? IOW, I suggest:
> > > 
> > > Because you are then trying to apply a patch series with some patches 
> > > potentially missing? Continuing only on errno == ENOENT seems prudent.
> > 
> > I fail to see how the absence of one of cur/ or new/ can lead to the 
> > absence of patches.  You could forget to save some patches, yes, but the 
> > presence of cur/ and new/ is no indicator for that.
> 
> Read my message again. Alex is proposing ignoring errors in opening the
> directories; I am proposing ignoring such errors _only_ when the error
> is that the directory does not exist.
> 
> IOW, if there is some other error in opening the directory, it should be
> fatal, because you might be missing patches.
Yeah, sorry, I missed that.

Ciao, Dscho

Karl Hasselström· Nov 6, 2007, 16:35 UTC · re: Johannes Schindelin · lore

Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

On 2007-11-06 15:51:09 +0000, Johannes Schindelin wrote:
Show 16 quoted lines
> On Tue, 6 Nov 2007, Jeff King wrote:
>
> > On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
> >
> > > I fail to see how the absence of one of cur/ or new/ can lead to
> > > the absence of patches. You could forget to save some patches,
> > > yes, but the presence of cur/ and new/ is no indicator for that.
> >
> > Read my message again. Alex is proposing ignoring errors in
> > opening the directories; I am proposing ignoring such errors
> > _only_ when the error is that the directory does not exist.
> >
> > IOW, if there is some other error in opening the directory, it
> > should be fatal, because you might be missing patches.
>
> Yeah, sorry, I missed that.

I think it might actually not be totally unreasonable to error out unless both directories exist. From http://www.qmail.org/qmail-manual-html/man5/maildir.html:

  A directory in maildir format has three subdirectories, all on the
  same filesystem: tmp, new, and cur.

In other words, if it doesn't have these three directories, it isn't a Maildir directory.

On the other hand, one could argue that requiring both dirs to exist is being too picky.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle
Johannes Schindelin· Nov 6, 2007, 16:58 UTC · re: Karl Hasselström · lore

Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

Hi,
On Tue, 6 Nov 2007, Karl Hasselstr?m wrote:
Show 31 quoted lines
> On 2007-11-06 15:51:09 +0000, Johannes Schindelin wrote:
> 
> > On Tue, 6 Nov 2007, Jeff King wrote:
> >
> > > On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
> > >
> > > > I fail to see how the absence of one of cur/ or new/ can lead to
> > > > the absence of patches. You could forget to save some patches,
> > > > yes, but the presence of cur/ and new/ is no indicator for that.
> > >
> > > Read my message again. Alex is proposing ignoring errors in
> > > opening the directories; I am proposing ignoring such errors
> > > _only_ when the error is that the directory does not exist.
> > >
> > > IOW, if there is some other error in opening the directory, it
> > > should be fatal, because you might be missing patches.
> >
> > Yeah, sorry, I missed that.
> 
> I think it might actually not be totally unreasonable to error out
> unless both directories exist. From
> http://www.qmail.org/qmail-manual-html/man5/maildir.html:
> 
>   A directory in maildir format has three subdirectories, all on the
>   same filesystem: tmp, new, and cur.
> 
> In other words, if it doesn't have these three directories, it isn't a
> Maildir directory.
> 
> On the other hand, one could argue that requiring both dirs to exist
> is being too picky.

Not only that. The recent patch for OSX' mail program would be trivial if we did not error out: the array would just contain cur, new and Messages.

Ciao, Dscho

Alex Riesen· Nov 6, 2007, 21:50 UTC · re: Karl Hasselström · lore

Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty

Karl Hasselström, Tue, Nov 06, 2007 17:35:48 +0100:
Show 25 quoted lines
> On 2007-11-06 15:51:09 +0000, Johannes Schindelin wrote:
> > On Tue, 6 Nov 2007, Jeff King wrote:
> > > On Tue, Nov 06, 2007 at 11:01:03AM +0000, Johannes Schindelin wrote:
> > > > I fail to see how the absence of one of cur/ or new/ can lead to
> > > > the absence of patches. You could forget to save some patches,
> > > > yes, but the presence of cur/ and new/ is no indicator for that.
> > >
> > > Read my message again. Alex is proposing ignoring errors in
> > > opening the directories; I am proposing ignoring such errors
> > > _only_ when the error is that the directory does not exist.
> > >
> > > IOW, if there is some other error in opening the directory, it
> > > should be fatal, because you might be missing patches.
> >
> > Yeah, sorry, I missed that.
> 
> I think it might actually not be totally unreasonable to error out
> unless both directories exist. From
> http://www.qmail.org/qmail-manual-html/man5/maildir.html:
> 
>   A directory in maildir format has three subdirectories, all on the
>   same filesystem: tmp, new, and cur.
> 
> In other words, if it doesn't have these three directories, it isn't a
> Maildir directory.

On the same line of reasoning, if opening a ".../cur" fails with ENOTDIR, it must be not a Maildir...

> On the other hand, one could argue that requiring both dirs to exist
> is being too picky.

...which MUST NOT mean it does not contain useful patches. IOW, the tool can try and apply everything it finds. If user told it to get patches from the...whatever, then the patches should it get and damn qmail.

Gerrit Pape· Nov 6, 2007, 08:54 UTC · re: Alex Riesen · lore

[PATCH amend] git-mailsplit: with maildirs not only process cur/, but also new/

When saving patches to a maildir with e.g. mutt, the files are put into the new/ subdirectory of the maildir, not cur/. This makes git-am state "Nothing to do.". This patch lets git-mailsplit additional check new/ after reading cur/.

This was reported by Joey Hess through
 http://bugs.debian.org/447396
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
On Mon, Nov 05, 2007 at 01:58:50PM +0100, Jakub Narebski wrote:
> > +        for (i = 0; i < 2; ++i) {
> Wouldn't it be better to use sizeof(sub)/sizeof(sub[0]) or it's macro
> equivalent ARRAY_SIZE(sub) instead of hardcoding 2 to avoid errors?
I made the array NULL-terminated.
On Mon, Nov 05, 2007 at 04:26:24PM -0500, Jeff King wrote:
> Isn't the subject line now wrong?
Yes, thanks.
On Mon, Nov 05, 2007 at 11:52:58PM +0100, Alex Riesen wrote:
> Why is missing "cur" (or "new", for that matter) a fatal error?
> Why is it error at all? How about just ignoring the fact?
As suggested by Jeff, I made it ignore the error on ENOENT.
 builtin-mailsplit.c |   38 ++++++++++++++++++++++----------------
 1 files changed, 22 insertions(+), 16 deletions(-)
Show changes to builtin-mailsplit.c +22 −16
diff --git a/builtin-mailsplit.c b/builtin-mailsplit.c
index 74b0470..46b27cd 100644
--- a/builtin-mailsplit.c
+++ b/builtin-mailsplit.c
@@ -101,20 +101,29 @@ static int populate_maildir_list(struct path_list *list, const char *path)
 {
 	DIR *dir;
 	struct dirent *dent;
+	char name[PATH_MAX];
+	char *subs[] = { "cur", "new", NULL };
+	char **sub;
+
+	for (sub = subs; *sub; ++sub) {
+		snprintf(name, sizeof(name), "%s/%s", path, *sub);
+		if ((dir = opendir(name)) == NULL) {
+			if (errno == ENOENT)
+				continue;
+			error("cannot opendir %s (%s)", name, strerror(errno));
+			return -1;
+		}
 
-	if ((dir = opendir(path)) == NULL) {
-		error("cannot opendir %s (%s)", path, strerror(errno));
-		return -1;
-	}
+		while ((dent = readdir(dir)) != NULL) {
+			if (dent->d_name[0] == '.')
+				continue;
+			snprintf(name, sizeof(name), "%s/%s", *sub, dent->d_name);
+			path_list_insert(name, list);
+		}
 
-	while ((dent = readdir(dir)) != NULL) {
-		if (dent->d_name[0] == '.')
-			continue;
-		path_list_insert(dent->d_name, list);
+		closedir(dir);
 	}
 
-	closedir(dir);
-
 	return 0;
 }
 
@@ -122,19 +131,17 @@ static int split_maildir(const char *maildir, const char *dir,
 	int nr_prec, int skip)
 {
 	char file[PATH_MAX];
-	char curdir[PATH_MAX];
 	char name[PATH_MAX];
 	int ret = -1;
 	int i;
 	struct path_list list = {NULL, 0, 0, 1};
 
-	snprintf(curdir, sizeof(curdir), "%s/cur", maildir);
-	if (populate_maildir_list(&list, curdir) < 0)
+	if (populate_maildir_list(&list, maildir) < 0)
 		goto out;
 
 	for (i = 0; i < list.nr; i++) {
 		FILE *f;
-		snprintf(file, sizeof(file), "%s/%s", curdir, list.items[i].path);
+		snprintf(file, sizeof(file), "%s/%s", maildir, list.items[i].path);
 		f = fopen(file, "r");
 		if (!f) {
 			error("cannot open mail %s (%s)", file, strerror(errno));
@@ -152,10 +159,9 @@ static int split_maildir(const char *maildir, const char *dir,
 		fclose(f);
 	}
 
-	path_list_clear(&list, 1);
-
 	ret = skip;
 out:
+	path_list_clear(&list, 1);
 	return ret;
 }
 
-- 
1.5.3.5
Junio C Hamano· Nov 8, 2007, 02:09 UTC · re: Gerrit Pape · lore

Re: [PATCH amend] git-mailsplit: with maildirs not only process cur/, but also new/

Gerrit Pape <pape@smarden.org> writes:
Show 25 quoted lines
> When saving patches to a maildir with e.g. mutt, the files are put into
> the new/ subdirectory of the maildir, not cur/.  This makes git-am state
> "Nothing to do.".  This patch lets git-mailsplit additional check new/
> after reading cur/.
>
> This was reported by Joey Hess through
>  http://bugs.debian.org/447396
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
>
> On Mon, Nov 05, 2007 at 01:58:50PM +0100, Jakub Narebski wrote:
>> > +        for (i = 0; i < 2; ++i) {
>> Wouldn't it be better to use sizeof(sub)/sizeof(sub[0]) or it's macro
>> equivalent ARRAY_SIZE(sub) instead of hardcoding 2 to avoid errors?
> I made the array NULL-terminated.
>
> On Mon, Nov 05, 2007 at 04:26:24PM -0500, Jeff King wrote:
>> Isn't the subject line now wrong?
> Yes, thanks.
>
> On Mon, Nov 05, 2007 at 11:52:58PM +0100, Alex Riesen wrote:
>> Why is missing "cur" (or "new", for that matter) a fatal error?
>> Why is it error at all? How about just ignoring the fact?
> As suggested by Jeff, I made it ignore the error on ENOENT.
Looks good to me.  Final acks please?
Jeff King· Nov 8, 2007, 02:31 UTC · re: Junio C Hamano · lore

Re: [PATCH amend] git-mailsplit: with maildirs not only process cur/, but also new/

On Wed, Nov 07, 2007 at 06:09:26PM -0800, Junio C Hamano wrote:
Show 6 quoted lines
> > When saving patches to a maildir with e.g. mutt, the files are put into
> > the new/ subdirectory of the maildir, not cur/.  This makes git-am state
> > "Nothing to do.".  This patch lets git-mailsplit additional check new/
> > after reading cur/.
> 
> Looks good to me.  Final acks please?
Fixed my concerns.
Acked-by: Jeff King <peff@peff.net>
-Peff
Alex Riesen· Nov 8, 2007, 07:24 UTC · re: Junio C Hamano · lore

Re: [PATCH amend] git-mailsplit: with maildirs not only process cur/, but also new/

Junio C Hamano, Thu, Nov 08, 2007 03:09:26 +0100:
Show 27 quoted lines
> Gerrit Pape <pape@smarden.org> writes:
> 
> > When saving patches to a maildir with e.g. mutt, the files are put into
> > the new/ subdirectory of the maildir, not cur/.  This makes git-am state
> > "Nothing to do.".  This patch lets git-mailsplit additional check new/
> > after reading cur/.
> >
> > This was reported by Joey Hess through
> >  http://bugs.debian.org/447396
> >
> > Signed-off-by: Gerrit Pape <pape@smarden.org>
> > ---
> >
> > On Mon, Nov 05, 2007 at 01:58:50PM +0100, Jakub Narebski wrote:
> >> > +        for (i = 0; i < 2; ++i) {
> >> Wouldn't it be better to use sizeof(sub)/sizeof(sub[0]) or it's macro
> >> equivalent ARRAY_SIZE(sub) instead of hardcoding 2 to avoid errors?
> > I made the array NULL-terminated.
> >
> > On Mon, Nov 05, 2007 at 04:26:24PM -0500, Jeff King wrote:
> >> Isn't the subject line now wrong?
> > Yes, thanks.
> >
> > On Mon, Nov 05, 2007 at 11:52:58PM +0100, Alex Riesen wrote:
> >> Why is missing "cur" (or "new", for that matter) a fatal error?
> >> Why is it error at all? How about just ignoring the fact?
> > As suggested by Jeff, I made it ignore the error on ENOENT.
Better.
> Looks good to me.  Final acks please?
Acked-by: Alex Riesen <raa.lkml@gmail.com>
Fernando J. Pereda· Nov 8, 2007, 07:31 UTC · re: Junio C Hamano · lore

Re: [PATCH amend] git-mailsplit: with maildirs not only process cur/, but also new/

On Wed, Nov 07, 2007 at 06:09:26PM -0800, Junio C Hamano wrote:
Show 29 quoted lines
> Gerrit Pape <pape@smarden.org> writes:
> 
> > When saving patches to a maildir with e.g. mutt, the files are put into
> > the new/ subdirectory of the maildir, not cur/.  This makes git-am state
> > "Nothing to do.".  This patch lets git-mailsplit additional check new/
> > after reading cur/.
> >
> > This was reported by Joey Hess through
> >  http://bugs.debian.org/447396
> >
> > Signed-off-by: Gerrit Pape <pape@smarden.org>
> > ---
> >
> > On Mon, Nov 05, 2007 at 01:58:50PM +0100, Jakub Narebski wrote:
> >> > +        for (i = 0; i < 2; ++i) {
> >> Wouldn't it be better to use sizeof(sub)/sizeof(sub[0]) or it's macro
> >> equivalent ARRAY_SIZE(sub) instead of hardcoding 2 to avoid errors?
> > I made the array NULL-terminated.
> >
> > On Mon, Nov 05, 2007 at 04:26:24PM -0500, Jeff King wrote:
> >> Isn't the subject line now wrong?
> > Yes, thanks.
> >
> > On Mon, Nov 05, 2007 at 11:52:58PM +0100, Alex Riesen wrote:
> >> Why is missing "cur" (or "new", for that matter) a fatal error?
> >> Why is it error at all? How about just ignoring the fact?
> > As suggested by Jeff, I made it ignore the error on ENOENT.
> 
> Looks good to me.  Final acks please?
Fixed my concern too.
Acked-by: Fernando J. Pereda <ferdy@gentoo.org>
-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

← back to recent threads