[PATCH 07/10] builtin-archive: mark unused prefix "unused_prefix"

cmd_archive() is registered without RUN_SETUP so its prefix
will be NULL forever. Let's make that clear.

Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
 builtin-archive.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/builtin-archive.c b/builtin-archive.c
index c2e0c1e..84405df 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c

@@ -236,11 +236,12 @@ static const char *extract_remote_arg(int *ac, const char **av)
 	return remote;
 }
 
-int cmd_archive(int argc, const char **argv, const char *prefix)
+int cmd_archive(int argc, const char **argv, const char *unused_prefix)
 {
 	struct archiver ar;
 	int tree_idx;
 	const char *remote = NULL;
+	const char *prefix;
 
 	remote = extract_remote_arg(&argc, argv);
 	if (remote)

@@ -250,9 +251,8 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
 
 	memset(&ar, 0, sizeof(ar));
 	tree_idx = parse_archive_args(argc, argv, &ar);
-	if (prefix == NULL)
-		prefix = setup_git_directory();
 
+	prefix = setup_git_directory();
 	argv += tree_idx;
 	parse_treeish_arg(argv, &ar.args, prefix);
 	parse_pathspec_arg(argv + 1, &ar.args);

-- 
1.5.4.2.281.g28d0e

Hi,

On Sun, 2 Mar 2008, Nguyễn Thái Ngọc Duy wrote:

cmd_archive() is registered without RUN_SETUP so its prefix
will be NULL forever. Let's make that clear.

Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---

AFAICT this patch is -- like two others -- an independent fix, and should 
be submitted as such.

Ciao,
Dscho

On Tue, Mar 11, 2008 at 8:33 PM, Johannes Schindelin
[off-list ref] wrote:

Hi,


 On Sun, 2 Mar 2008, Nguyễn Thái Ngọc Duy wrote:

 > cmd_archive() is registered without RUN_SETUP so its prefix
 > will be NULL forever. Let's make that clear.
 >
 > Signed-off-by: Nguyễn Thái Ngọc Duy [off-list ref]
 > ---

 AFAICT this patch is -- like two others -- an independent fix, and should
 be submitted as such.

It's not really independent. Before the series, setup_dir_gently()
_can_ change the prefix. After the series it does not (semantics
change). The first patch of the series ("git read-tree -m") is
independent and can be cherry picked if necessary.
-- 
Duy

I hate to make this request, but Gmail seems unable to decode messages
which are "Content-Disposition: inline" + "Content-Transfer-Encoding:
base64". The message body shows up completely blank in the Gmail web
interface. (I wonder if it is due to the footer that Majordomo appends?)

I've reported this is a bug to Gmail, but since I imagine I'm not the
only one using Gmail to read this list, and since so far your messages
seem to be the only ones sent this way, can I ask that you configure
your MUA to not send messages this way, if possible?

Much appreciated,

j.

On Tue, Mar 11, 2008 at 10:38 PM, Jay Soffian [off-list ref] wrote:

I hate to make this request, but Gmail seems unable to decode messages
 which are "Content-Disposition: inline" + "Content-Transfer-Encoding:
 base64". The message body shows up completely blank in the Gmail web
 interface. (I wonder if it is due to the footer that Majordomo appends?)

Funny that meesage was created by gmail.

 I've reported this is a bug to Gmail, but since I imagine I'm not the
 only one using Gmail to read this list, and since so far your messages
 seem to be the only ones sent this way, can I ask that you configure
 your MUA to not send messages this way, if possible?

If I does not misunderstand it, non-ascii characters make gmail encode
messages base64. I'll be careful next time removing all non-ascii (or
switch back to mutt).

 Much appreciated,

 j.

-- 
Duy